# Adoption Stories

By [DYLIT Chronicles](https://dylit.info/user/dylitmediabuzz)

[Everything AI - beyond the hype](https://dylit.info/pr/everything-ai-beyond-the-hype/6a9efac02e92664f4d50cf9d) > [Adoption Stories](https://dylit.info/ch/adoption-stories/6a9efac02e92664f4d50cfca)

The Team That Started With One Tedious Task The most effective rollouts rarely begin with a strategy. They begin with somebody being annoyed. A four-person customer support team at a logistics company. Every Friday afternoon, someone spent two hours reading the week's tickets and writing a summary for the operations lead: what broke, what customers complained about, what is recurring. Nobody enjoyed it. It was genuinely useful, which is why it survived, and it consumed the worst two hours of the week. Why this was the right first task Not because it was important. It was not, particularly. It was the right first task because of its shape. It recurred. Every week, reliably. Any improvement compounded rather than being a one-off win. All the information was already there. The tickets contained everything needed. Nothing had to be looked up, remembered or invented. Text in, text out. Somebody knew what good looked like. The person who had written it forty times could tell immediately whether a generated version was right, which meant errors would be caught rather than shipped. Failure was cheap. A bad summary meant twenty wasted minutes, not an unhappy customer. That combination is the profile of a good starting point, and it is worth checking against before picking anything. What they did Exported the week's tickets. Stripped customer names and account numbers, replacing them with placeholders. Pasted the text in with a prompt asking for themes, with the number of tickets in each, and a representative example for each theme quoted directly from the source. The first attempt was mediocre. It produced sensible categories that were too broad to act on. "Delivery issues" covered forty percent of tickets and told the operations lead nothing he did not know. The fix was one sentence added to the prompt: no category may cover more than fifteen percent of tickets, split broader ones into specific causes. That produced something genuinely better than the human version had been. "Delivery issues" became four distinct causes, one of which nobody had noticed as a pattern because it had never been counted. The unexpected part The time saving was real: two hours became about twenty-five minutes, most of it checking. But the thing that mattered more was that the summary got better. A person reading two hundred tickets holds impressions. A systematic pass counts them. The team had been reporting what felt significant, which is not the same as what was frequent. Within two months the operations lead was making routing decisions off that summary. It had gone from an obligation to an input. This pattern recurs often enough to be worth expecting. The initial justification for automating a task is time. The durable value frequently turns out to be that the task is now done more thoroughly than a person under time pressure ever did it. What they did next Nothing, for six weeks. They ran the same workflow, refined the prompt twice, and left it alone. Then a second task, chosen on the same criteria: recurring, all information present, someone able to judge the output, cheap to get wrong. Converting resolved tickets into knowledge base articles. Two workflows, after four months. Both reliable, both documented, both still checked by a person before anything went out. Why the slow pace was right The temptation after a success is to apply it everywhere at once. That is how rollouts fail. Six weeks of running one workflow surfaced the edge cases: the weeks with unusual ticket volumes, the categories that needed adjusting, the occasions the model over-summarised and lost something. All of that learning transferred to the second workflow and made it faster to get right. A team that had launched five workflows simultaneously would have had five half-working processes and no clear sense of which problems belonged to which. The transferable bit Ask your team one question: what is the most tedious text-based thing on your plate? The answers will be unglamorous. Nobody nominates a strategic initiative. They nominate the weekly summary, the meeting notes, the categorising, the reformatting. Those unglamorous answers are usually the right place to start, because tedium is a reliable signal that a task is repetitive, well understood, and low risk. Which is the exact profile of work these tools handle well.