Before writing that your product saved a customer hours each week, explain what the original work involved. Who performed it? What did the measured hours include? What requirements did the new process have to meet?
That starting point is the case study’s before-state: the customer’s workflow before adoption, the problem’s documented cost or consequence, and the constraints on changing it. It gives prospective buyers enough context to judge whether the result applies to their situation.
Build one evidence sheet, then use it to write a short baseline section. The worksheet below covers workflow, timeframe, costs, and customer language.
Choose one workflow to describe
Start with a recurring job: assigning incoming support requests, preparing a customer report, or reviewing an AI-generated answer before sending it. Define where the work began and when it was complete.
A description such as “a fast-growing software business” offers little basis for comparison. Include details that explain the task: how many people handled it, its weekly volume, the tools involved, and the quality standard they had to meet. Company revenue belongs here only if it helps explain the workload, purchasing constraint, or outcome.
Record what already worked. Perhaps the spreadsheet was accurate but required repeated copying. Perhaps the process handled routine requests well but stalled on exceptions. Those details explain both the reason for changing the process and what the customer needed to preserve.
Interview for a specific episode, then check the records
Ask the customer to reconstruct an instance of the work from before adoption. Follow the sequence from the initial request to the finished task.
The GOV.UK Service Manual recommends open, neutral questions and a focus on real examples. Its guidance addresses service research more broadly, but the interview approach is useful for reconstructing a customer’s workflow. Read the interview guidance.
Use these prompts as a starting point:
- Walk me through the last time you completed this task before switching.
- What started the work, and how did you know it was finished?
- Who touched it, and where did it wait?
- Which steps required checking or redoing work?
- What happened when the process took longer than expected?
- What had you already tried, and what had to stay the same?
- Which records could help us check the timing, volume, or cost?
Separate active work from waiting time. A request that took two days to resolve may have required only 20 minutes of labor. Record which measure the customer means before using it in a comparison.
Keep the customer’s exact language separate from your summary. Save the speaker, interview date, and recording timestamp or note reference. Present paraphrases as paraphrases; a sentence produced by an AI writing assistant is not a customer quotation.
Define the baseline and its evidence limits
For each fact you might publish, retain its source and the period it describes. An export may support a count; an interview may support a customer’s recollection. Label the evidence accordingly:
| Status | What to record |
|---|---|
| Recorded | The dated export, invoice, time log, or other record supporting the claim |
| Estimated | Who reconstructed the figure, how they did it, and what remains uncertain |
| Unknown | What is missing or too ambiguous to use |
A recorded number still needs a definition. “Handling time” might cover initial review, every staff interaction, or elapsed time until closure. State the start and end points, included work, sample size, and exclusions. A dated document alone does not show that its measure fits your claim.
Choose a period that represents the workflow you are describing. Check whether a launch, outage, holiday, staffing shortage, or unusually difficult workload affected it. If an exceptional week triggered the purchase, explain that role and distinguish it from ordinary work.
Keep software spending, labor estimates, and documented revenue effects separate. Multiplying staff hours by an hourly cost estimates the value of that labor. Reduced effort may free capacity without reducing payroll, so the calculation does not establish cash savings.
If nobody measured the old process, write a qualitative baseline. Describe the handoffs and attribute the reported burden to the customer. State that historical timing was not recorded, and leave out a percentage improvement that depends on that missing measurement.
Work through a hypothetical support baseline
This example is fictional. Its team, records, and numbers illustrate the method; they are not customer evidence.
Suppose a three-person SaaS support team is considering an AI tool that suggests ticket categories. Its case study draft begins:
Before adoption, manual ticket triage was slow and expensive.
The writer assembles this hypothetical evidence sheet:
| Field | Hypothetical finding | Evidence status within the example |
|---|---|---|
| Period | Four ordinary workweeks before the pilot | Record the actual dates in a real case study |
| Scope | 800 incoming tickets requiring initial triage | Recorded count |
| Workflow | Read ticket, choose category, assign owner | Description to confirm with staff |
| Labor | 40 staff hours logged for initial triage | Recorded time |
| Exclusions | Replying, resolution, and later reassignment | Measurement boundaries |
| Constraint | Staff must approve suggested categories | Requirement to confirm with the customer |
| Labor cost | Assumed loaded rate of $45 per hour | Assumption used for the calculation |
| Cost of incorrect routing | Unavailable | Unknown |
The average is 40 hours × 60 minutes ÷ 800 tickets = three minutes of initial triage labor per ticket. That figure excludes resolution time and customer waiting time.
At the assumed labor rate, 40 hours × $45 = $1,800 of estimated labor value for the four-week period. It is a baseline cost estimate, not an amount saved. The example provides no evidence for a dollar cost of incorrect routing.
The before-state paragraph can now describe what the records support:
Before the pilot, three support specialists manually categorized and assigned incoming tickets. Across four ordinary workweeks, they logged 40 hours of initial triage for 800 tickets, averaging three minutes per ticket. That measure excluded replies, resolution, and later reassignment. The proposed workflow still required a specialist to approve each suggested category.
The paragraph replaces “slow and expensive” with defined work and a measured burden. It leaves out the dollar estimate because the rate is only an assumption. If you include such an estimate in a real story, state the rate, its basis, and the calculation alongside it.
A later comparison would need to include human review and correction time for initial triage and use a comparable workload. It should also examine routing quality, since faster assignment alone would leave part of the customer’s requirement unanswered.
Keep the later comparison within the same boundaries
Document other changes that could affect the result. Did the customer add staff, update its help center, narrow the types of requests it accepted, or change its definition of a completed task?
UK government guidance on evaluating digital health products warns that a before-and-after study cannot establish with certainty that the product caused the improvement. Applied to a SaaS story, that caution means reporting observed changes without attributing all of them to the product. Read the before-and-after study guidance.
For an AI product, specify how much human work remained. If the old baseline includes review and correction, the later measurement should account for those steps too. Comparing a finished manual task with an unreviewed generated draft measures different stages of the work.
Keep the story’s conclusions within the evidence: what was measured, what the customer reported, and what remains uncertain.
Copy this before-state worksheet
Complete this worksheet for one workflow. Keep source references in your working document and carry the definitions and limitations that affect interpretation into the published story.
| Field | Your notes |
|---|---|
| Customer context | Team, workload, and other details relevant to this task |
| Workflow | Start and completion points; people, tools, and handoffs |
| Baseline period | Actual dates, why you chose them, and any unusual conditions |
| Scope | Workload, sample size, included steps, and exclusions |
| Baseline measure | Metric, value, unit, and measurement method |
| Evidence | Source reference and recorded, estimated, or unknown status for each claim |
| Cost, if used | Calculation, rate, and assumptions; distinguish labor value from spending |
| Consequence | What the problem affected and the evidence supporting that connection |
| Constraints | What worked and what any replacement had to preserve |
| Customer language | Exact wording, speaker, source reference, and quote approval |
| Comparison limits | Other changes that could affect a later result |
| Gaps | Missing information, who can clarify it, and which claim it limits |
Then draft from this paragraph template:
During [period], [team] handled [defined workload] using [workflow]. The process involved [relevant steps and handoffs]. [Record or attributed customer estimate] showed [baseline measure, with units and scope]. This affected [supported consequence]. Any replacement needed to preserve [constraint]. [Material uncertainty or exclusion].
Omit optional details that do not help readers evaluate the situation. If evidence is missing, remove or qualify the affected claim. Keep limitations that change how the result should be understood.
Review the baseline and assign the next task
Ask the person who performed the work to check the workflow description and the owner of the records to check the numbers. These may be different people. Have them check each figure’s unit, period, definition, and source, including any assumptions in calculated costs.
Then have the customer review the wording, confirm quotations, and approve the final version before publication. HubSpot’s case study workflow likewise separates draft feedback from final approval. Approval does not replace checking the supporting evidence. See its case study preparation guide.
Once the full story is approved, use the customer story reuse map to plan excerpts that retain the context behind the result.
Take one outcome claim from your next case study and complete the worksheet for its starting point. For each gap, name the person who can verify it and the claim you will narrow or omit if the evidence remains unavailable. Use the completed sheet to write the baseline paragraph before polishing the headline.
