Fictional Case Study: Reducing Duplicate Customer Requests

Fictional learning scenario

This is an original RDE teaching case. The organisation, records, observations and outcomes are invented for learning. It is not a client case, testimonial or report of real results.

Context and decision to make

A fictional training provider receives course enquiries through a web form and email. Staff see repeated requests and propose buying a new ticketing system. A business analyst is asked to clarify the problem before the provider commits to a purchase.

Evidence available in the scenario

For the learning exercise, the first sample contains 40 incoming messages over five working days. After matching course, sender reference and enquiry purpose, the team identifies 30 distinct enquiry cases. Ten messages are additional contacts about existing cases. Six of those ten follow a web submission that gave no reference number; four arrive after the stated response window. These are invented records, not customer data or a real performance report.

Approach and interpretation

The analyst distinguishes incoming messages from distinct cases. A second message is not automatically an error: someone may supply missing information or change their request. The team reads the ten additional messages, maps when acknowledgements were sent and asks what the sender could reasonably know about progress. The evidence points to uncertainty about receipt and response timing. It does not show that a new system is necessary.

Options and decision

Three options are considered: purchase a ticketing platform; add a reference and a clear acknowledgement using the existing process; or leave the process unchanged while collecting another sample. The team chooses a small acknowledgement trial because it addresses the observed uncertainty with limited operational change. A staff member owns the reference register, and enquiries that cannot be matched remain separate until checked.

Outcome within the fictional scenario

During a second fictional five-day sample, the provider receives 35 messages representing 30 distinct cases. Five messages are additional contacts. Additional-message count therefore changes from 10 to 5; the share of incoming messages changes from 25% to about 14.3%. The first response window remains the same. Staff also record two mismatches where a reference was copied incorrectly and correct them before combining records.

Limitations and next checks

The trial is consistent with fewer additional contacts, but it does not prove that the acknowledgement caused the change. Different enquiry types, sender behaviour and the small sample may explain part of the result. A lower message count is not a benefit if legitimate follow-up information is lost. The provider continues the trial and checks unresolved cases and incorrect matches before deciding whether a larger system is justified.

Apply the case

Allow about 20 minutes. Identify the decision, extract the evidence and write down one assumption that needs checking. Separate the observed or stipulated figures from the explanation proposed by the team.

1. Why must incoming messages and distinct cases be counted separately?
2. What evidence would make the acknowledgement explanation stronger?
3. How would you prevent a legitimate changed request being merged into the wrong case?

Check your learning

Keep the definition with the count. Improve a visible gap before buying a larger solution, and check that the change does not suppress useful contact.

A useful response names the unit being measured, tests the proposed explanation against the available evidence and proposes a next check that could change the decision. Avoid claiming a general result from the small fictional sample.

Use and attribution

Original educational scenario by Jefferson Otonbara Imgbi. Version 1.0, 8 October 2026. No real customer records, organisation identities or endorsements are used. Personal and internal organisational learning use permitted with author credit retained.

Cover image: AI-generated illustrative scene created specifically for this resource.