Priya runs a support team of thirty at a mid-sized software company. Her agents lose a good chunk of every ticket hunting through old tickets and help articles for something that resembles the customer’s problem. Last quarter she ran a little trial. The tool is a drafter. It reads each message, trawls the knowledge base, and proposes a reply; the agent corrects it, then sends. Nothing goes out untouched.
It’s a modest experiment, and a decent snapshot of where generative AI pays its way. Forget the grand transformation. The wins hide in corners of the day: reading, searching, summarizing, drafting. Next come the most common use cases, what each one needs, and one way to choose where to start.
Searching your own documents
Tomás in sales operations needs the latest security questionnaire answers before a two o’clock call. He knows the document exists. Is it on the shared drive? The wiki? An email from March? No idea. He tries an AI search tool instead and types the question. The answer comes back drawn from the right document, link included, so he can confirm it. Under the hood it’s called retrieval-augmented generation, or RAG. Tomás just sees a search box that talks back. Two conditions apply: the documents have to be in decent shape, and the tool has to know who may see what. Nobody wants an intern’s question to surface the executive pay file.
Code
Mei, a backend developer, wants the fifth endpoint, the one that looks exactly like the other four. Her assistant produces it, along with tests and a docstring. Mei reads the lot, fixes two things, and it’s live before lunch. Fast, routine, and read line by line by a person: these tools are at their best there. Anything near logins, payments or outside input still needs a careful person. Weighing platforms? Choosing an AI coding platform for enterprise has the questions worth asking.
Long documents
Daniel handles insurance claims. Today he has a forty-page report to get through. He needs dates, parties, amounts and anything strange. The manager upstairs wants one page, no more. A minute later the tool has the fields extracted and the page drafted. Daniel checks both against the original, because a quiet error in a summary has a way of becoming a decision by Thursday. That checking step isn’t optional.
Marketing copy
Carla in marketing owes four hundred product descriptions, and the brand voice guide has gathered dust. She feeds the tool a dozen examples she likes and gets four hundred drafts back. A single read tells her whether one is usable, so she edits fast. It’s why marketing often shows results first.
Questions for your data
Ravi runs a region. Suppose he types “which region missed target last quarter?” and gets a polished chart. Is it right? Only if the data is tidy and people agree what “customer” means. When three teams each define “customer” their own way, Ravi gets three answers, all equally confident.
IT operations
At ten at night, after an outage, somebody has to write the post-incident review. A tool can draft it from the ticket history and the chat logs. Not glamorous, and very welcome.
What the first month looks like
Back to Priya. In week one her agents distrust the drafts and rewrite nearly everything. By week three they know the pattern. Billing questions and password resets come out fine. The strange bugs that need real digging do not. Every Friday Priya posts a tally: drafts sent as they were, drafts edited, drafts binned. From it she can see where the knowledge base needs work and which ticket types to switch off. It’s also the evidence she shows her director when asked whether the experiment is worth continuing.
What Priya told her director
At the end of the quarter the director asked one question: do we keep going? Priya came with the Friday tallies and a short story. The agents found the tool useful on routine tickets and useless on strange ones, which matched what the numbers showed. The knowledge base was in better shape than it had been in years, a benefit nobody had planned for. The director agreed to a second phase, on one condition: agents keep deciding what gets sent. That condition came as no surprise, since it had been the design from day one.
The costs people forget
The invoice is only part of it. In month one, Priya’s team put more hours into the knowledge base than into the tool. Someone also had to make sure the tool couldn’t read confidential tickets. Agents needed an hour of training and a place to report bad drafts. Add usage fees, which grow with ticket volume, and the cost of a person who owns the whole thing. None of it is dramatic, but a plan that ignores it will look cheaper than it is.
How to pick the first one
Look again at why Priya’s experiment was a sensible choice. There’s a lot of text. The task repeats all day. A person reviews every output. It’s easy to measure: how long to a first reply, how long to close. And the knowledge base already existed.
Now a poor first choice: a bot answering billing disputes alone, in public, from day one. The stakes are high. Reviewing it is hard, and undoing it harder. Same technology, different lesson. Just the first one is safe to learn on.
On your own list, begin with tasks that come up constantly, drown in text and carry little risk. Keep a person in the loop and choose one number to track. Write that number down before you start.
Where these projects go wrong
If you blame the model, you’ll usually be wrong. Usual suspects: documents gone stale, an old process nobody measured, a tool parked in a corner of the intranet while the team carries on as before. A business owner, a training plan and an honest review after two months fix most of that.
If you want help choosing and building, our generative AI services cover the whole path. For what a good advisor should bring, read what enterprises should expect from generative AI consulting, and for the build side, what goes into production-ready language model applications.
Modernize with confidence. Build for what's next.
Talk to our team about embedding AI into the core of your business.