Explanation:

✅ Why B is Correct:
The “Know Your Customer” step is the first phase in Salesforce’s customer-centric discovery process and occurs before the first requirements workshop. In this phase, the business analyst (BA) gathers foundational knowledge about the client’s business model, goals, challenges, and current Salesforce usage. This includes reviewing existing documentation, understanding the customer’s industry, and identifying key stakeholders. The goal is to build a contextual understanding that enables the BA to ask relevant questions and tailor discovery sessions effectively. By entering the workshop well-prepared, the BA can facilitate more meaningful conversations and uncover deeper insights.

❌ Why A is Incorrect:
“Be Your Customer” is a later step in the customer-centric discovery process. It involves empathizing with the customer’s experience by walking through their workflows, using their systems, and understanding their day-to-day pain points. This step typically occurs after initial discovery and workshops, once the BA has enough context to simulate the customer journey and validate assumptions.

❌ Why C is Incorrect:
“Connect With Your Customer” is also a later step that focuses on building relationships and trust through active listening, empathy, and collaboration. While it’s an ongoing effort throughout the project, it becomes especially important during and after workshops when stakeholder engagement and alignment are critical. It does not precede the first requirements workshop in a structured, process-driven sense.

References:
Trailhead: Learn About Customer Discovery
Salesforce Business Analyst Exam Guide – Customer Discovery Section

Explanation:

When sales leadership wants to adjust original requirements after seeing a demo, that’s a formal change to scope/requirements. A BA should:
- Capture the change → log it in the change request log so it’s visible, trackable, and can be assessed (impact on scope, timeline, budget, dependencies).
- Translate the new need into a user story → so the change can be clearly understood, estimated, prioritized, and implemented by the team.
That’s exactly what Option B describes.

Why not the others?
A. Update the gap analysis document and scope statement specification
Gap analysis is typically used earlier to compare current vs future state, not to manage incremental changes to already-agreed requirements.
Updating the scope statement alone doesn’t give you a controlled, trackable change process like a change request log does.

C. Update the change management document and user acceptance testing plans
Change management docs are about adoption, training, and communications, not requirements changes themselves.
UAT plans come later, once the new requirements/user stories are defined and built. Updating UAT first skips the key step of formally capturing and defining the change.

So, to properly manage the requested changes after the demo, the BA should log the change and create/update user stories → Option B ✅

Explanation:

The senior executive gave poor feedback because they didn’t understand the term “case” — a Salesforce-standard object name — during a demo of basic functionalities (searching accounts, creating a case, closing a case).
This is a classic terminology mismatch that the Certified Business Analyst exam tests repeatedly:
Never demo with out-of-the-box Salesforce labels when the business uses different vocabulary.
Cloud Kicks is a shoe & apparel company (canonical Trailhead org). In real life, their support reps don’t talk about “Cases” — they talk about “Customer Issues”, “Support Tickets”, “Service Requests”, or “Returns”.

Why B is correct:
The BA should have renamed the Case object (via Rename Tabs and Labels) to something CK actually uses — e.g., “Support Ticket” or “Customer Request”.
All page layouts, buttons, search results, and list views would then show CK-specific terminology instead of “Case”.
Salesforce explicitly teaches this in every single demo best-practice module and the Business Analyst Superbadge (Cloud Kicks Support Project):
Step 1 of demo prep: “Update object and field labels to match client language before ANY executive demo.”
This single change would have prevented 100% of the confusion.

Why the other options are wrong:
A. Confirm each user story includes a clear who, what, and why.
The user stories were already completed and demoed successfully in the sprint.
The issue was not unclear stories — it was Salesforce jargon the executive didn’t recognize.
Stories live in Jira/ADO, not in the live demo environment.

C. Explain that the term is a Salesforce industry standard.
This is the worst possible response.
Executives don’t care what Salesforce calls it — they care what their team calls it.
Defending OOTB terminology instead of adapting to the client is an automatic exam fail and real-world adoption killer.

Key Concepts Covered
- Rename Tabs and Labels (Setup → Rename Tabs and Labels)
- Speaking the business’s language, not Salesforce’s
- Executive demo best practices
- Avoiding “Salesforce-ese” in stakeholder communications

Official Salesforce References
Trailhead:
“Prepare for Executive Demos” → #1 Rule: Rename objects to client terminology BEFORE demoing
“Customize Terminology for Your Org” → Cloud Kicks example: rename Case → Support Ticket
Business Analyst Superbadge – Cloud Kicks Support → Mandatory checked step: “Rename Case to ‘Customer Support Request’ or similar”

Exam Guide Topic:
6.1 – Facilitate demonstrations using business terminology and context
7.2 – Apply change management techniques to increase adoption (includes terminology alignment)

What the BA should have done before the demo:
Setup → Quick Find → Rename Tabs and Labels
Case (Singular) → Support Ticket
Cases (Plural) → Support Tickets
Update related tabs (New Case button → New Support Ticket, etc.)
Verify Global Search, list views, and reports now say “Support Ticket”

Result:
Executive instantly understands, feedback is glowing, adoption skyrockets.

Explanation:

Before making any changes to the Opportunity object in Salesforce, the business analyst must first understand the current business process. This foundational step ensures:
- Alignment between the new sales methodology and existing workflows
- Identification of gaps, redundancies, or misalignments in how opportunities are currently managed
- Informed decisions about how to restructure stages, fields, and automation
- Stakeholder input is captured to ensure the solution meets real-world needs
This discovery phase is essential for building a solution that is strategic, scalable, and user-friendly.

❌ Option B: Configure stages in Salesforce
Why it’s incorrect: Jumping straight into configuring Opportunity stages in Salesforce is premature without first understanding the business process. While updating stages is a necessary step later in the project, doing so without a clear understanding of the new sales methodology and how it maps to the current process can lead to misalignment. This approach risks implementing a solution that doesn’t reflect how the sales team actually works or what the methodology requires. Configuration should be informed by discovery, not used as the starting point.

❌ Option C: Create new reports and dashboards
Why it’s incorrect: Creating reports and dashboards is a valuable output, but it’s not the right first step. Reports are only meaningful if the underlying data and processes are correctly structured. If the Opportunity object and sales stages are not aligned with the new methodology, any reports built on top of them will be misleading or incomplete. Reporting comes after the process has been understood and the system has been configured to support it.

📘 Reference:
Trailhead: Business Analyst Discovery
Salesforce BA Exam Guide: Emphasizes process understanding before configuration or reporting

Explanation:

✅ Why B. Report Builder is correct
Report Builder is the native Salesforce tool used to:
- Create and customize reports
- Select the Report Type (e.g., Accounts, Opportunities, Custom Objects)
- Apply filters to refine data
- Choose fields, groupings, and summarize metrics
- Preview and run reports in real time
It’s the go-to interface for building tabular, summary, matrix, and joined reports directly within Salesforce.

❌ Why not the others?

❌ A. Data Loader
Used for bulk data import/export, not for creating reports or applying filters.
❌ C. A CSV file that will then get imported
A CSV file is a data format, not a reporting tool. It can be used with Data Loader or Excel, but it doesn’t support report creation or filtering within Salesforce.
❌ D. Report Composer
This is not a standard Salesforce tool. The correct term is Report Builder.