An ops executive at a D2C brand that sells on its own site and on two marketplaces has a return request open, and the courier pickup window closes at four. The new assistant sits in the bottom corner of the order dashboard as a chat box. It demoed well in the Friday review, and six weeks later almost nobody opens it. She never wanted a conversation. She wanted the reply to that return drafted on the screen she was already on, using the order the system already had.
Start from a step the screen already has
Pick a screen people open every day and find the one step on it that is slow because it needs some judgement over text. Writing the summary of a support ticket. Drafting the reply to a dealer's query. Turning a meeting note into three follow-up tasks. Choosing the category for an incoming vendor invoice. The model does that one step, and the rest of the screen stays exactly as it was.
That changes what you build. There is no open text field asking how it can help. There is a button on the ticket that says "Draft a reply", a suggested category sitting next to the invoice, a proposed task list under the note. Take an admissions counsellor at a coaching institute with forty enquiries waiting after a weekend. She opens one, and the screen already shows a draft reply in Hindi with the batch dates and fees for the course the student asked about. She never asked what the model can do. Her question was whether she can answer this family before they call a competitor.
Framing it this way also gives you something to watch. A chat box gets judged on a vague sense of satisfaction. A draft reply gets judged on how often it goes out with few edits, and you can argue about that number in a review meeting. Most of the LLM application work on our AI solutions page starts from a step like this one.
Gather what the user should not have to type
A model only knows what is in the request. In a chat box, the user supplies all of it by typing, which is why chat-box answers are so often generic: the model never saw the order, the earlier messages or the house style. People blame the model. The request was empty.
A feature built into the task gathers that context itself before anything is sent. First the record on screen, whether that is the ticket, the invoice or the contract clause. Then the related records, such as the customer's last three tickets or the SKU the order refers to. Then the reference material that sets the rules: the return policy, the tone guide, the list of categories the finance team accepts in Zoho Books. Last, the user's one explicit choice, if there is one at all, such as shorter or longer, Hindi or English.
- 01User clickson the record
- 02App gathersrecord, history, rules
- 03Model
- 04App checksformat, required fields
- 05Shown in placewith sources, editable
Most of the request is assembled by the application, not typed by the user.
Deciding this list is most of the design work, and we usually spend the first workshop on nothing else. It is also where the data path gets decided. Whatever the application gathers leaves for the model, so the list is where you drop fields that have no business in the request. A customer's PAN does not help write a reply about a delayed parcel. Leave it out. When the reference material is large, the gathering step becomes retrieval, which our post on what a RAG pipeline actually does walks through.
Show the sources and the state
Output that appears as plain text asks the user to trust it blindly, and most people stop doing that after the first bad draft. Two things make it usable.
Show the sources. If the draft quotes the return policy, show which clause. If the summary refers to an earlier ticket, link it. The ops executive can check in seconds instead of re-reading the whole thread, because she is not reading the draft, she is scanning it for the one line that might be wrong. You can only cite what you passed in, so retrieval and citation get designed together.
Show the state. A request takes a few seconds and sometimes fails, more often on a counsellor's phone on patchy 4G. The screen needs a visible "drafting" state, a visible failure with a retry, and a clear line between a suggestion and a saved change. The model's output should never quietly become the record. The user accepts, edits or discards it, and that action is what gets stored.
What a chat box hides
The chat box is popular because it hides the hard parts, and hiding them is also why it stops being used.
- User types the context
- Prose to copy out
- No link to the record
- Failure looks like a bad answer
- Only usage to measure
- App supplies the context
- Output lands in its field
- Sources beside it
- Failure has a retry
- Accept and edit rate
The same model, placed differently, gives the user very different amounts of work.
It hides the missing inputs, so a vague answer looks like a weak model. It hides output checking, because nobody verifies that a free-text answer carries the fields the next step needs. It hides cost per use, since nothing limits how long a conversation runs; we cover the controls for that in caching, routing and budgets per user. And it hides the copy and paste at the end, where the user selects the text, switches tab and pastes it into the helpdesk. That step is the first one people give up on, usually in the second week.
The mistakes we see most
Shipping the chat box first "to learn what users want", then finding the logs full of questions the product already answers two taps away. Letting the model's text overwrite a record with no accept step, so three months later nobody can say which part of a customer note a person wrote.
Sending the whole record because the input list was never designed, Aadhaar fields included. Showing a confidence score the model never produced; if you cannot measure it, do not display it. And treating output format as a prompt problem. A reply that must carry an order number should be checked in code before anyone sees it, not politely requested in the prompt.
Before you build, a yes on each of these
- The feature is named after the task, not after the model.
- Every input in the request is listed, with where it comes from.
- The output lands in a specific field, and the user accepts it explicitly.
- Sources appear wherever the output relies on a document.
- Loading, failure and retry each have a visible state.
- One number tells you whether it works: accepted drafts, edits per draft, or time to close.
Then put a clickable version in front of five people who do the task every day, and watch where they hesitate. Write the input list before that session. Once you know what the request contains, the screen, the data path and the way you measure the feature follow from it.
