The Chatbot Charter: Solution Named Before the Need
Northvale Health System has three hospitals and 40 outpatient clinics. Its patient portal, launched four years ago, is used by 12% of active patients; the call center handles 4,800 scheduling calls a week and 22% of them are abandoned. At the steering committee, the CIO announces that the answer is an AI scheduling chatbot and asks for a charter by Friday. The vendor demo showed a 60% deflection rate. The CMO wants the chatbot too, but the nursing director says the real problem is that clinic templates were never standardized after the merger, so patients cannot find slots. The CFO has approved $450,000 for the chatbot and is unwilling to fund discovery. You are the BA, assigned Monday; the charter is due in four days. No business case exists, and the last two IT initiatives had adoption below 30%.
1. What do you do first with the sponsor's chatbot directive, given the four-day charter deadline?
Read the worked answer
Start by reframing, not resisting. The sponsor has named a solution before the need is defined, which is the classic needs-assessment failure this exam tests. My first move is a short conversation with the CIO to agree on what the charter must contain: a situation statement, measurable business objectives, scope boundaries, assumptions, constraints, and known risks - not a product decision.
I would write the charter around the problem: 4,800 weekly scheduling calls, 22% abandoned, 12% portal adoption, and unstandardized templates after the merger. The chatbot goes under assumptions or candidate solutions, not scope. The $450,000 approval is recorded as a constraint. I would insert a two-week, time-boxed discovery phase with a decision gate before any build commitment, funded from the existing envelope.
Then I would use the BACCM to test the change: is the chatbot a need, a solution, or a stakeholder want? The nursing director's claim points to a process and template root cause. I would not sign a charter that treats a vendor demo's 60% deflection as a forecast. I would document the risk that a third sub-30% adoption outcome is likely if templates are the real constraint, and ask the CIO to approve the discovery gate in writing.
2. Which techniques would you use in four days to test whether a chatbot addresses the need, and what evidence would change your recommendation?
Read the worked answer
Four days cannot support a full study, but it can support cheap, disconfirming evidence:
- Data analysis: pull 200 recent abandoned calls and code the reasons. If most are 'no available slot' or 'template mismatch' rather than 'could not reach a human', a chatbot will not fix abandonment.
- Document analysis: compare scheduling templates across the three hospitals for the top 20 appointment types. Variance in slot lengths and rules would support the nursing director.
- Observation: sit with four schedulers for two hours each to see workarounds and call content.
- Interviews: 15 minutes each with the CMO, nursing director, and two clinic managers.
- Benchmarking: ask two peer systems with patient portals what deflection they actually sustained after go-live.
The evidence that would change my recommendation is a high share of calls that are simple, repetitive, and answerable from data the portal already holds - confirmations and rescheduling, for example. If the sample instead shows availability and template problems, I would recommend standardizing templates first and positioning the chatbot as a later phase with the same funding.
3. How do you handle the conflict between the CFO's no-discovery constraint and the lack of a business case?
Read the worked answer
Handle it transparently; do not pretend discovery is free or hide it inside the build estimate. The charter would show the $450,000 as a constraint and a phased scope: Phase 1 discovery and template assessment (two weeks, a small slice of budget), Gate 1 decision, Phase 2 chatbot pilot, Phase 3 rollout. Objectives would be outcome-based - reduce abandoned scheduling calls from 22% to below 10% and raise portal adoption - not 'deploy a chatbot'.
I would bring the sponsor a decision with options: (A) approve the two-week gate, (B) approve a chatbot pilot limited to the highest-volume, simplest call types while discovery runs, or (C) proceed without discovery and accept the adoption risk. Each option gets cost, risk, and evidence needs. This respects the CFO's authority while making the risk visible.
I would also log assumptions: that the vendor's deflection rate applies to our call mix, that templates can be standardized within budget, and that clinic managers will participate. If the sponsor chooses C, I would document the accepted risk in the charter and risk register and proceed, because the BA informs the decision; the sponsor owns it.