Direct answer
Use a story that shows four things: you took the complaint seriously and reproduced it, you told the customer what you knew and did not know at each stage, you found a specific root cause, and you changed something so it cannot recur silently. The story below is an illustrative shape, a composite built to show the structure. Replace the details with your own real example, and use your own real numbers; do not copy these placeholders as if they were results.
Story skeleton (STAR: situation, task, action, result)
Situation. I worked on a scoring model that ranked a company's business customers by the risk of cancelling their subscription (a "churn risk" score; churn means customers leaving), used by the customer's account managers each Monday. One account manager told us the model was ranking clearly healthy accounts as high risk, and she was about to stop using it.
Task. Find out whether she was right, keep her informed, and make sure it could not happen again quietly.
Action, investigation.
- I asked her for three specific accounts and what she expected, instead of debating the model in general. Three concrete cases can be reproduced; a general doubt cannot.
- I checked the inputs for those accounts, not the model first. The "days since last login" value was extremely large for all three, though they were active. Tracing back, an upstream change to single sign-on (SSO, one login for many applications) had made the login-time field empty for those users, and our pipeline (the automated steps that prepare data before the model sees it) replaced empty with zero, which the model read as "has not logged in for years". Why: the login field is a date, and a stored zero means 1 January 1970, the starting point computers count dates from, so "days since last login" came out at over 20,000 days, more than 55 years, for a customer who logged in yesterday.
- I measured the scope: how many of the accounts scored that week had that field empty (I reported it as N of M, with the exact figures from the data; in an illustrative case, 312 of 1,480 accounts scored that week, about 21%, had the field empty).
Action, communication along the way.
- Same day: "Thanks, I can see why it looks wrong. I'm checking the three accounts and will report back tomorrow."
- Next day: "What we know: the login-time input is empty for some accounts and is being read as inactive. What we do not know yet: how many accounts. Until it is fixed, please disregard the risk ranking for accounts with SSO."
- On fix: what was wrong in plain terms, which scores changed, and when corrected scores would reappear.
Action, prevention. I added a check that stops scoring and alerts us if the share of empty values in any input jumps above a set threshold (for example, alert if more than 2% of an input is empty when it normally runs below 0.5%). I changed the pipeline to treat empty as "unknown", not zero. And I added the three accounts as permanent test cases. I also wrote a short post-incident note shared with the customer. Its shape: "What happened: after a login change, some accounts had no login time and were scored as inactive. Who was affected: 312 accounts, scored on Monday 6 October. What we did: corrected the data and rescored; corrected rankings were in your inbox on Wednesday. What changes: we now stop scoring and alert us if inputs go missing."
Result. Corrected scores were delivered; the account manager kept using the model; the new check later caught a different input problem before any customer saw it. If you have measured outcomes in a real story (accounts corrected, time to resolution, number of recurrences), state them with their real values.
What separates a strong answer
- You started with the customer's concrete examples and reproduced the problem.
- You told them what you knew and did not know, and gave interim guidance, instead of waiting for a full answer.
- The fix addressed the cause (an input assumption) and the system (a check), not just the symptom.
- You did not blame the customer or the upstream team.
Pitfalls
Do not claim the customer was wrong without evidence. Do not describe only the technical fix; the communication is half of the question. Do not tell a story with no change at the end.
