Last year a client asked for an AI agent to automate their customer complaint triage. Forty hours of scoping done, two weeks of build time blocked. I was three days from opening the IDE when I sat next to the customer service team for two hours and watched.
I expected to see overwhelmed agents drowning in tickets. What I saw was three CS staff handling 12 complaints a day each, perfectly fine, with one exception — they refused to escalate anything to the operations team. Not because escalations were hard. Because the SOP for escalation was 11 steps long, contradicted itself in steps 4 and 7, and the last person who escalated “incorrectly” got a written warning.
The complaint volume was not the problem. The fear of escalation was. The triage agent I was about to build would have processed tickets faster into a system the team was already afraid to use.
I killed the project. Rewrote the escalation SOP from 11 steps to 4. Ran a 30-minute training. Two weeks later, complaints were down 60%. Zero lines of code shipped. The client saved 40 hours of dev time and $8K of cloud budget.
Since then I have had the same conversation five more times. Different industry, different “we need an app” request, same ending: a procedure nobody had bothered to write down clearly was doing the work that 200 hours of engineering could not.
This is the part of design thinking nobody talks about. Most of the time, the right output of the empathy stage is not a prototype. It is a one-page procedure that everyone can read, agree on, and follow. The build comes later — if it comes at all.
Read more