Software case study interview questions: find the useful customer story

Agree the scope with the customer

Explain the subject, intended audience and proposed use of the interview. Identify the people who can discuss the workflow and approve factual details for publication. Arrange recording or note-taking through an agreed process and keep unnecessary private information out of the material.

For a fictional scheduling-software vendor, the customer might be a maintenance company. A manager can explain the buying decision, while a dispatcher can describe everyday use. One enthusiastic executive quotation may not establish how the operational process actually changed. Choose interviewees who can speak to the relevant work.

Ask about the earlier process

Start with a recent example from before the implementation. What information arrived, who handled it and where did the work wait? Ask which part was difficult and what the team did to manage it. Avoid beginning with a statement that the old process was broken.

For the maintenance company, follow one appointment from customer request to technician assignment. Record the tools and handovers involved. Ask which difficulties were frequent and which were exceptional. This helps the article describe the actual context rather than implying every business in the sector has the same problem.

Use open follow-up questions

GOV.UK’s interview guidance describes planning topics and follow-up questions in a discussion guide. Apply that discipline to the case study: ask the customer to explain an example, then follow the parts that need clarification.

Useful prompts include What happened next?, Who made that decision? and Can you describe a specific occasion? Avoid asking How much time did our amazing software save? because it supplies both the judgement and the expected result. Give the customer room to describe a limitation or an outcome the writer did not anticipate.

Build the interview around evidence

The table is a suggested interview structure, not a substitute for listening. Follow the customer’s account and clarify contradictions. Keep claims attributed to the person or evidence that supports them.

Treat numbers as claims to verify

Ask for the definition, period and basis of any improvement figure. Distinguish a measured report from an estimate or recollection. If several process changes occurred at the same time, record them rather than attributing every outcome to the software.

For the maintenance company, a reduction in dispatch effort might reflect cleaner incoming data as well as the scheduling tool. The article can explain both. Do not invent a percentage to make the story look stronger. A precise account of a changed handover can be useful even when the customer cannot substantiate a numerical return.

Separate observation and interpretation

GOV.UK’s analysis guidance distinguishes what was observed or heard from the interpretation applied afterward. Keep that distinction while writing. A customer’s statement about one team should not become a claim about every customer or an entire industry.

Check quotations against the agreed record and send factual details through the agreed approval process. Preserve meaningful limitations. If the customer cannot approve publication of a detail, remove or appropriately revise it rather than replacing it with an unverified assertion. Keep permission to use names, images and supporting material explicit.

Turn the interview into a useful article

Structure the story around context, decision, implementation, current workflow and supported outcomes. Include the constraints that help another buyer judge relevance. Avoid a sequence of praise quotations with no explanation of the work.

SoftwareRadar’s publishing enquiry can be used to propose a software case study with an available interview contact. The article-format guide helps compare other formats, while the distribution guide covers later reuse. A strong story gives readers evidence they can assess in their own context.

Frequently asked questions