Explanation:

The Scope section of a SOW defines:
What work will be done (deliverables, activities, services).
Who will do the work (responsibilities of consultant vs. client).
How it will be delivered (training approach, documentation, workshops).
Training users on new features is a project deliverable → so it belongs in the Scope section.

❌ Why Not the Others
B. Background → Provides project context and objectives, not specific responsibilities or delivery methods.
C. Terms and Conditions → Covers legal, payment, timelines, intellectual property, and liability, not training deliverables.

Reference:
Standard SOW structure: Background → Scope → Deliverables → Roles/Responsibilities → T&Cs.
Training & enablement always defined in Scope of Work.

Explanation:

Matching Rules and Duplicate Rules: In Salesforce, a Matching Rule identifies potential duplicate records by defining the criteria for what constitutes a duplicate (e.g., matching a lead's email and phone number). However, a matching rule alone doesn't prevent duplicates from being created.

Activation is Key: For the matching rule to take effect, it must be used by an active Duplicate Rule. A Duplicate Rule specifies what action to take when a duplicate is found, such as alerting the user or blocking the record from being saved. The consultant's role is to ensure the custom matching rule is properly configured and activated within a corresponding duplicate rule to actively prevent or warn against duplicate leads.

Why the other options are incorrect:
A. Change the criteria for the standard Lead Matching Rule. Salesforce provides standard matching rules, but they often don't fit every organization's specific needs. The admin has already created a custom matching rule, which is the correct approach. Modifying the standard rule isn't the primary solution. The issue isn't the criteria itself but whether the rule is active and in use.

B. Confirm the standard Lead Matching Rule is deactivated. Deactivating the standard rule is not a necessary step to use a custom one. Both can exist, but only one is typically used within a duplicate rule. The core issue remains the activation of the custom rule.

Explanation:

🔍 Why Option B Is Best:
Since Contact OWD is set to "Controlled by Parent", access to Contacts is inherited from the related Account. Therefore, if you want the sales ops specialist and sales engineer to have access to Contacts, you need to ensure they have access to the Account.
Account Teams are designed exactly for this:
You can assign multiple roles (e.g., Sales Ops Specialist, Sales Engineer) to an Account.
Each role can be configured with default access levels to Accounts, Contacts, Opportunities, and Cases.
Once added to the Account Team, users automatically gain access to the Account and its related Contacts (because of the OWD setting).

❌ Why the Other Options Don’t Fit:
A. Add the Sharing button to the page layout
This allows manual sharing, which is not scalable or efficient for CK’s structured team assignments.
C. Change Contact OWD to Private and use sharing rules
This breaks the current inheritance model and adds complexity. You’d need to manage separate sharing logic for Contacts, which is unnecessary if Account Teams are used.

🧠 Consultant Tip:
Use Account Teams with default team roles and access levels to streamline visibility and maintain scalability. This aligns with best practices for role-based access in collaborative sales environments.

Explanation:

Northern Trail Outfitters is seeing an increase in logged activities, but not in actual bookings — which suggests that reps may be logging quantity over quality. The VP suspects a misunderstanding of the activity measures, meaning reps might be focusing on meeting numeric targets rather than engaging in meaningful sales actions.

✅ Why Option B Is Correct:
Training on targeted interactions helps reps understand which activities drive results, such as discovery calls, demos, or proposal follow-ups.
It aligns reps with the intent behind the metrics, not just the numbers.
This approach improves sales effectiveness, not just compliance with activity tracking.

❌ Why the Other Options Don’t Fit:
A. Deploy Sales Engagement and use Cadences
While helpful for structured outreach, this doesn’t address the root issue: reps misunderstanding the purpose of activity measures. Cadences could reinforce the wrong behaviors if not paired with proper training.
C. Reevaluate Opportunity stages
Opportunity stages reflect pipeline progression, not rep behavior. Changing stages won’t fix the misunderstanding around activity quality.

📘 Reference:
Trailhead: Sales Strategies and Best Practices
Salesforce Help: Activity Management

Explanation:

Before enabling Einstein Lead Scoring and Einstein Deal Insights, the consultant should first assess whether Universal Containers’ org is ready for these features. That’s where the Einstein Readiness Assessor comes in.

✅ Why Option A Is Correct:
The Einstein Readiness Assessor evaluates your org’s data quality, volume, and structure to determine if Einstein features can be successfully implemented.
Running it in a sandbox allows safe analysis without impacting production.
It helps identify any gaps in data (e.g., missing fields, insufficient historical records) that could affect model accuracy.
This step ensures a strategic and informed rollout of Einstein features.

❌ Why the Other Options Don’t Fit:
B. Enable Einstein Activity Capture in a developer org
A developer org is not representative of real data. Activity Capture is useful, but not the first step for implementing Lead Scoring or Deal Insights.
C. Enable both Einstein features in production
Enabling features without assessing readiness can lead to poor model performance, wasted effort, and confusion. It’s premature without validation.

📘 Reference:
Salesforce Help: Einstein Readiness Assessor
Trailhead: Sales Cloud Einstein