Explanation:

The BA has just joined an existing Sales Cloud project and is tempted to impress the customer quickly. The correct and professional approach is to first understand the customer’s actual needs, pain points, and priorities before jumping into configuration or development.

Why A (Demo standard features and elicit feedback from the customer) is the Correct Choice
Sales Cloud has hundreds of powerful out-of-the-box features (Dynamic Forms, Path, Einstein Opportunity Scoring, Dynamic Dashboards, etc.) that many customers under-utilize.
Demoing relevant standard functionality is fast, carries zero technical debt, and often delivers immediate value.
Most importantly, it forces discovery: while showing standard features, the BA asks “Is this helpful?”, “What’s missing?”, “How do you do this today?” — instantly gathering requirements and building credibility.
This aligns perfectly with Salesforce’s “Adopt before you extend” philosophy and is the quickest, safest way to create visible wins and impress the customer.

Why B (Update the page layouts to show the most relevant information at the top) is Not Correct
Changing page layouts without first understanding user roles, priorities, or current pain points risks moving important fields out of sight or creating confusion. It looks like action, but it’s presumptive configuration that can easily backfire.

Why C (Scope the development of an integration with enterprise resource planning (ERP)) is Not Correct
Starting to scope a complex, expensive, and time-consuming ERP integration is the opposite of “quickly introducing new functionality.” It is a multi-month effort with high risk and cost — the last thing a new BA should propose when trying to make an early positive impression.

Reference
Salesforce Trailhead: Accelerate Value with Out-of-the-Box Features – “Always demo and adopt standard functionality before building custom solutions.”
Salesforce Success Guide: “The fastest way to show value in an existing implementation is to surface underused standard features through guided demos and feedback sessions.”

Explanation:

Good acceptance criteria define the conditions of satisfaction from the user's perspective, focusing on the outcome and value, not the implementation.

Option A is excellent because it states what the user needs to achieve ("view current information") and where ("directly in the Lead and Contact records"). It is clear, testable, and does not dictate how the integration should be built (e.g., via a widget, a component, a related list). This leaves the solution open for the technical team to design the best implementation.

Analysis of Other Options:

B. A sales rep needs to have the CRM widget installed in the Lead and Contact Record Page Layout.
This is a solution-specific requirement and a poor example of acceptance criteria. It dictates the how (a "CRM widget") and the where ("Page Layout") instead of focusing on the user's goal. The development team might have a better way to display the information, but this criteria locks them into one method.

C. Install a CRM widget to allow sales reps to view information in the Lead and Contact records.
This is even worse than option B, as it is written as a technical task or a command for the development team, not as a condition for the user story. It completely violates the purpose of acceptance criteria.

Reference:
This aligns with the best practice of writing "What" instead of "How" in acceptance criteria. Good criteria are:
Testable: A QA tester can verify that a sales rep can see the information in the record.
Clear & Unambiguous: "Current information" and "directly in... records" provide clear boundaries.
Focused on User Value: It describes the benefit the user will receive.

Explanation:

You ran a group workshop, documented the in-scope processes, and now you see gaps between steps. That usually means:
Some steps were skipped or assumed.
Hand-offs between people/teams aren’t clearly described.
Exceptions or variations weren’t fully discussed.

The best next move is to go back to the people who actually do those parts of the process and elicit more detail—through follow-up interviews, smaller workshops, or observation. That’s exactly what option A describes.

Why not B or C?

B. Review the documentation to ensure that information gathered about the process is correct.
You should review your notes, but if you already see gaps, just rereading won’t create missing information. You still need more input from stakeholders.

C. Using strategy analysis, define models of how gaps in the business process can be resolved.
That’s jumping ahead to solution / future-state work.
You first need to confirm the current state process; only then should you use strategy analysis to design improvements.

So to close the gaps or confirm the process:
👉 A. Conduct elicitation with stakeholders regarding their parts of the process.

Explanation:

The current user story —
"As a service agent I want Salesforce Macros to complete repetitive tasks faster." — mentions a specific solution (Salesforce Macros) rather than focusing on the user’s goal or need.

In Agile best practices, user stories should describe what the user wants to achieve, not how to achieve it. This keeps the story solution-agnostic, allowing the team to explore the best implementation.

🔁 Improved User Story Example:
"As a service agent, I want to reduce the time spent on repetitive tasks so I can focus more on helping customers."

This version:
Focuses on the goal (reducing time on repetitive tasks)
Leaves room for the team to decide whether Salesforce Macros or another tool is the best solution

❌ Why not the others?

❌ B. Change the user story to the sales manager persona
This option misaligns the user persona. In Agile, the persona in a user story should represent the end user who directly interacts with the feature or experiences the benefit. In this case, the service agent is the one using Salesforce Macros to complete repetitive tasks. Changing the persona to the sales manager, who merely suggested the feature, would disconnect the story from the actual user’s needs and context. The sales manager may be a stakeholder, but they are not the primary user of the feature.

❌ C. Add a quantifiable reason why the feature is needed
While adding quantifiable metrics (e.g., “reduce task time by 30%”) can enhance a user story during refinement, it’s not the first or most critical improvement needed here. The current story prematurely mentions a specific solution (Salesforce Macros), which violates the principle of keeping user stories goal-focused and solution-agnostic. Before quantifying impact, the story must first be reframed to focus on the user’s goal — such as reducing time spent on repetitive tasks — without prescribing how that goal should be achieved.

Reference:
Trailhead: Agile User Stories
Salesforce BA Certification Guide

Explanation

The finance team is introducing a new post-Closed/Won sales process in Sales Cloud, and several requirements still need refinement. Process documents (e.g., process flows, decision matrices, validation rules, approval steps) will evolve as requirements are clarified. The BA needs a reliable, auditable way to track every change to these living documents over time.

Why C (Version control) is the Correct Choice
Version control (e.g., Git, Salesforce DevOps Center, Gearset, Copado, or even shared drives with strict naming conventions and change logs) is the industry-standard method for tracking modifications to any project artifact, including process documents, requirements specifications, and diagrams. It provides:
Full change history (who changed what and when)
Ability to compare versions and roll back if needed
Clear audit trail for governance and sign-off
Collaboration without overwriting each other’s work

Salesforce BAs working on regulated or complex processes (especially finance-related Closed/Won revenue recognition, order fulfillment, or contract handoff) are increasingly required to maintain version-controlled documentation.

Why A (Communication template) is Not Correct
A communication template is used to standardize emails, meeting notes, or status updates. It does not track document changes or maintain historical versions.

Why B (Business backlog) is Not Correct
The business or product backlog tracks features and user stories to be built (e.g., “Add validation rule on Closed/Won opportunities”). It is not designed to version-control the process documents themselves—only the work items derived from them.

Reference
Salesforce Trailhead: Manage Requirements and Documentation – “Use version control systems (such as Git) for all requirements artifacts and process documents to maintain an audit trail of changes.”

Salesforce DevOps Center & Best Practices: Explicitly recommends version-controlling requirements, process flows, and decision matrices alongside code.

Final Answer: C