Turn a vague request into a decision brief

Understand the method

A request often arrives as an output: “Make a dashboard,” “Show whether performance improved,” or “Tell us if the new process worked.” Those phrases leave important choices unresolved. Before opening a spreadsheet, find out who will use the answer, what decision is pending and what evidence would change that decision. A useful analysis plan connects the work to that choice. It also makes the limits of the available evidence visible before somebody relies on the result.

Your case: Harbor Helpdesk

Harbor is a fictional customer-support team, separate from the Northstar Shop case in Foundations. Its operations manager introduced a routing process on 8 June 2026. The manager says: “The response chart looks better. Can you prove the new routing worked so we can extend it to every queue next Monday?” A training extract contains 24 tickets created during 1–14 June. You have no randomized assignment, staffing hours, implementation costs or longer historical baseline. The case notes also say that chat entry visibility and the staff rota changed around the same time.

Separate three things

Decision

Whether to extend routing now, continue a limited pilot or investigate first.

Question

How did recorded response timeliness differ between the two creation cohorts, overall and within channel, and what can this extract support?

Output

A short evidence note supported by reconciled tables and a reproducible method.

A dashboard is one possible output. It is not a substitute for specifying the question. “Prove it worked” assumes the desired conclusion. Replace it with a neutral question that can produce a disappointing or inconclusive answer. The analyst should not promise a rollout recommendation before reviewing the evidence.

Clarify only what matters

Ask who approves rollout, what “worked” means, which queues were actually exposed, whether response time means human or automated response, and what safety or service measures must not deteriorate. Ask when the decision is needed and what smaller deliverable would still help. “What chart colour do you prefer?” can wait. Learning whether routing covered only one queue cannot wait, because it changes the population and interpretation.

Record answers with their source. The supplied case brief is teaching authority for this exercise, not an actual stakeholder interview. Where an answer is unavailable, label an assumption or a data request. Do not manufacture a management approval, a budget or a service policy. A clear unresolved question is more useful than an invented certainty.

Build the brief

Use six headings: audience, decision, neutral question, scope, deliverable and limitation. A first draft can say: “Help the operations manager decide whether the pilot is ready for broader evaluation. Compare four-hour first-response timeliness for tickets created in the two specified weeks, report channel composition and a 72-hour resolution guardrail, then document alternative explanations.” This is useful descriptive work. It cannot isolate the effect of routing from concurrent changes.

Before proceeding, ask whether each sentence is a supplied fact, an agreed requirement or an analyst proposal. Keep those categories distinct. The stakeholder retains responsibility for approving operational action; your role is to provide an honest evidence base and a proportionate next step.