A real case study: problem → diagnosis → decision → implementation → outcome

A useful case study has five parts: the visible problem, the constraint underneath it, the decision that was made, what was actually implemented, and an outcome described factually — with a number only if it was measured. Most consulting case studies skip the second and fifth parts. Here is one of mine, in full, so you can see the method.

Problem — what was visibly wrong

A trading business ran sales and service on WhatsApp. Quotes and confirmations were typed by hand from chat into the ERP, late or never. They asked for an AI bot to reply faster.

Diagnosis — the hidden constraint

Every reply contained a decision: a price, a discount, a confirmation. The rules for those decisions lived in people's heads — under a certain amount anyone, above it a manager, for certain customers the owner. A reply bot would have sent prices nobody approved and been switched off within a week.

Decision

Do not automate the reply. Automate the preparation, and design the approval. Write the thresholds down. The AI prepares; the owner decides.

Implementation

Mapped the ten most common conversations and the copy step in each. Drew approval thresholds by amount and customer. Built the flow: request identified, record looked up, suggested price prepared, sent to the right person's phone, one tap to approve, then the quote generated from the system of record and sent into the chat.

Outcome — factual

Quotes come from the system of record. Approvals reach the owner on their phone. No more hand-copying between WhatsApp and the ERP for that flow. I have not put a percentage on it because the client did not measure cycle time before we started, and I will not invent one.

Lesson

Start with the approval, not the feature. The same structure — problem, what I saw, what changed, outcome, lesson — runs through every case on the site.

Next step

If this is the problem you are dealing with, see the case studies, or read Start with the approval, not the feature.