Assessing Solutions and Recommending Action

Assessing Solutions and Recommending Action

Quick Answer: CBDA Competency 5.3 asks you to assess proposed solutions and recommend action using analytics evidence plus feasibility, risk, strategy alignment, and constraints. Prefer structured recommendations: what to do, who owns it, when, how success is measured, and what risks remain—including when a pilot is wiser than full rollout.

Competencies 5.1–5.2 ensure results are sufficient for a decision tier. Evidence-based support structures options. Competency 5.3 is where Domain 5 becomes operational: you evaluate solution candidates and make a professional recommendation. On scenario items, weak options sound vaguely positive (“leverage insights to drive value”); strong options are specific, constrained, and owned.

What Competency 5.3 Covers

Assessing a solution means answering:

1. Does this solution address the business need the analytics illuminated?
2. Can the organization implement it given real constraints?
3. What risks and side effects accompany implementation?
4. Is it aligned with strategy, policy, and ethics?
5. What action should be taken now versus later?

A “solution” in CBDA language is not only a machine learning model. It may be a process change, pricing policy, staffing rule, product feature, marketing treatment, data quality program, or decision policy that uses analytics outputs.

Assessment Dimensions

1. Feasibility

A model with excellent offline metrics fails feasibility if scores arrive three days late for a same-day decision, or if agents have no time to act on alerts.

2. Risk

Risk assessment for analytics solutions should cover:

• Model risk — Wrong predictions, drift, feedback loops, adversarial behavior.
• Operational risk — Alert fatigue, process breakage, capacity spikes.
• Customer / employee harm — Unfair treatment, privacy intrusion, poor experience.
• Financial risk — Cost overruns, failed ROI, lock-in to a vendor.
• Reputational / regulatory risk — Misleading claims, discriminatory outcomes, consent failures.
• Strategic risk — Distraction from higher-value initiatives.

Rate likelihood and impact qualitatively if quantitative risk models are unavailable. Recommend controls (monitoring, human review thresholds, kill switches) not just risk adjectives.

3. Alignment with Strategy and Constraints

Even a feasible, low-risk solution can be wrong if it fights strategy:

• Optimizing short-term conversion in a brand-premium strategy that prioritizes trust.
• Cutting support costs when strategy is “best-in-class service.”
• Expanding data collection when strategy is privacy leadership and minimization.

Constraints to check explicitly: budget caps, headcount freezes, contractual SLAs, data residency, union rules, accessibility, and brand guidelines. Analytics recommendations that ignore published constraints score poorly in CBDA judgment scenarios.

Solution assessment scorecard (practical)

Weights should reflect this decision’s priorities—not a universal formula.

Pilot vs Full Rollout Recommendations

Choosing scale of commitment is a classic Competency 5.3 fork.

Prefer pilot / phased rollout when

• Evidence strength is moderate or segment coverage is partial.
• Operational capacity is unproven at full volume.
• Harm from errors is asymmetric and learning can reduce it.
• Stakeholders need proof before funding scale.
• Model or process is new to the organization (change risk high).
• Ethics/fairness monitoring is not yet mature for full population impact.

Prefer full rollout (or faster scale) when

• Evidence is strong, including successful pilots or robust experiments.
• Delay cost is high and residual risk is accepted with controls.
• Solution is low blast radius and highly reversible even at scale.
• Regulatory or safety drivers require organization-wide consistency and evidence supports readiness.
• Capacity and playbooks are already proven.

Pilot design elements that belong in the recommendation

• Scope — Population %, segment, region, channel.
• Duration — Time-boxed with interim checks.
• Success metrics — Primary outcome + guardrails (complaints, cost, fairness metrics).
• Kill criteria — What results stop expansion.
• Learning goals — What uncertainty the pilot is meant to reduce (VOI link).
• Owner — Business owner and analytics support owner.

A pilot without success metrics is just a slow full rollout with less honesty.

Structured Recommendation Format

CBDA-style recommendations should be decision-ready. Use a consistent skeleton:

1. Action — Imperative and specific (“Run a 10% random pilot of retention offer R2 on voluntary-cancel high-risk accounts in the US web channel”).
2. Owner — Named role (“VP Customer Success owns; Analytics provides weekly score refresh”).
3. Timing — Start date, duration, decision checkpoint (“Start next sprint; 6-week pilot; go/no-go on week 7”).
4. Success metric — Primary and secondary (“Primary: 60-day voluntary cancel rate; Secondary: offer cost per retained account; Guardrail: NPS and complaint rate”).
5. Risks and controls — Top residual risks and mitigations (“Risk: support overload—control: cap daily offers; Risk: model drift—control: weekly PSI monitoring”).
6. Dependencies — Data, legal, tech, training.
7. What we are not recommending — Explicit non-actions (“Do not full-rollout until pilot success criteria met”).

Example recommendation (condensed)

Action: Pilot personalized onboarding path B for 15% of new SMB accounts.
Owner: Head of Onboarding; Data BA supports measurement.
Timing: Launch April 7; evaluate at day 45.
Success metric: 90-day activation rate +15% relative vs control; guardrail—support tickets per account not >10% higher.
Risks: Selection bias if opt-in—use random assignment; privacy—minimize attributes to approved set.
Not recommended: Company-wide path replacement before evaluation.

This structure is longer than a slogan and shorter than a novel—ideal for exam reasoning and real practice.

Linking Analytics Findings to Solution Design

Assessment fails when the solution is disconnected from findings:

Competency 5.3 rewards mechanism-aware recommendations: the solution should act on a lever the analysis supports, within constraints.

Recommendation Traps on the Exam

From Recommendation to Influence

A strong recommendation still needs influence skills (covered more in later Domain 5 sections on change and resistance). Assessment quality, however, is the foundation: stakeholders are easier to move when the recommendation is feasible, risk-aware, and measurable. Competency 5.3 is the bridge from “we know something” to “here is what we should do next.”

Mini End-to-End Scenario

Need: Reduce preventable churn in month 2–3 of subscription.
Results: Unresolved support tickets associate with higher cancel; moderate evidence; retail-web only.
Options: Do nothing; full loyalty discount; ticket SLA + save offer pilot.
Assessment: Discount is costly and weakly tied to mechanism; SLA+save is feasible if capped; evidence partial → pilot.
Recommendation: 8-week pilot on 20% of at-risk retail-web accounts; owner CX Ops; metric cancel rate and ticket age; risks capacity and fairness of offer eligibility; no full rollout until criteria met.

That paragraph is Competency 5.3 in action—and the pattern CBDA wants you to reproduce under exam time pressure.