Freshservice · Freshworks · 2026 · Early access
Smart Reply: putting an AI draft inside the agent's editor, without taking the decision away
Proactive reply suggestions for IT support agents, gated on confidence. When the model isn't sure, the agent sees nothing rather than something plausible.
- Role
- Lead product designer — sole designer on the reply surface
- Team
- Copilot (generation) · Freshservice (reply editor) · Product · Design
- Timeline
- July 2026 → early access · the “90 days, 90 features” push
- Surface
- Freshservice ticket detail · Froala reply editor · desktop
Problem
The knowledge was in the box and the box wouldn't open
Mid-market and enterprise IT teams had been on Freshworks for years, and had years of resolved tickets sitting in the product doing nothing. One customer downloaded twelve months of their own ticket data, fed it to ChatGPT, and kept feeding it new tickets so their agents could search past resolutions. They asked us why the product they already paid for couldn't do that.
That was the villain. Not "agents type slowly." Accounts were evaluating a move off the base product over it.
What the agent is actually doing
An L2 IT agent picks up a ticket routed to them an hour ago. Before they can write anything they have to reconstruct context: the description, the requester's two follow-ups, and the private notes where an L1 already tried something. Then they search solution articles, and if that fails, they try to remember which ticket last month looked like this one. Only then do they start typing, usually a lightly-edited version of a reply they have written thirty times.
The expensive part was never the typing. It was the reconstruction, and it happened on every ticket, including the ones where the answer already existed in the system, twice.
Business bet: better assistance at the moment of reply reduces first-response and handle time, and raises tickets resolved per agent.
Reframe
The real problem wasn't generating text
Agents already had four ways to invoke AI in the editor: Refine with AI, Reply with AI, canned responses, and the Copilot slider. Adding a fifth entry point was the easy part and the wrong frame.
The actual problems were:
- Is this suggestion relevant? An agent can't tell without reading it, and reading it costs the time the feature was supposed to save.
- How do I act on it? Accept, edit, replace, ignore, and the difference between each.
- What happens when it's wrong? Recovery had to be cheaper than never using the feature.
So I stopped designing a button and started designing a state machine inside a text editor that already contains four other kinds of content: a saved draft, manually typed text, an inline suggestion, and whatever Copilot just returned.
Decisions
1. Proactive, but only when the system has earned it
Tension: showing something fast drives adoption; showing something weak burns trust permanently.
Options: always return a reply · hold a loading state until one exists · explicitly return nothing.
Chose: gate on source availability and generated-response confidence, with an explicit "No recommendations available" state. The system also refuses to re-suggest a solution the customer was already given in an earlier turn.
Because: a visible failure is cheaper than a plausible unreliable answer. An agent who gets burned twice never presses Tab again.
Cost: some qualifying events produce nothing, which makes the feature look less available than it is.
2. The banner that lost to the placeholder
Tension: agents needed to know a suggestion existed before opening the editor.
Options: an availability pill in the ticket timeline · a dismissible banner above the editor · a container with accept/reject buttons around the suggestion · ghost text in the placeholder position.
Killed the pill: it collided with the existing "x new messages" pill, two meanings in one visual slot.
Killed the banner and the container: a suggestion behaves like a placeholder. It should vanish the moment you start typing. A banner with a close button doesn't behave that way, and an action nested inside a container inside a reply editor read as three layers of chrome for one decision.
Chose: ghost text in the placeholder position, contrast raised above the default placeholder grey so it clears accessibility thresholds. Availability is signalled by a dot on the Reply action, top and bottom of the ticket, with a "Smart reply available" label. A dot alone tells you something happened, not what.
3. Tab is fast. Tab is also the focus key.
Tension: Tab-to-insert is a learned gesture from Gmail and every IDE. It's also how keyboard and switch users move through an interface.
Pushback (an engineering reviewer on motor access; I pushed the same point on focus order): hijacking Tab breaks normal navigation, and a shortcut-only affordance excludes touch and alternative-input users entirely.
Chose: keep Tab and Esc for the pointer-light path, but make the suggestion clickable, give it a hover-to-insert state, and move toward explicit Insert / Remove controls, with Insert receiving focus so Enter confirms it without stealing Tab.
Cost: explicit controls add visual weight to an editor already dense with formatting, templates, attachments, canned responses and articles.
Removal is plural on purpose: Esc, typing anything, or making any other change to the editor body (attaching a file, inserting an article) all clear it, because any of those is new context the suggestion was not generated against. This decision comes back to bite me in Results.
4. Don't replace the old menu yet
Tension: the new suggestion is strictly more capable than "Reply with AI," so the clean answer is to replace it.
Pushback: two reviewers flagged that agents shouldn't have to click every option to learn which ones insert text instantly and which open the Copilot slider. "Generate reply" and "Suggest resolution steps" looked identical and behaved differently.
Chose: keep both, but regroup the menu by outcome, insert instantly versus chat with Copilot, and phase the old options out only once adoption and quality data justify it.
Because: removing a tool people use daily before you know your replacement is better is a support ticket, not a migration.
Cost: a longer menu, and some conceptual overlap we knowingly shipped.
Two answers I had to go get from engineering
Why not just feed the new ticket-context pipeline into the existing "Reply with AI"? The new agentic platform pulls from sources the legacy path was never structured for: solution articles, similar tickets, resolution notes, private and public notes, through a different API shape. Retrofitting it into the old options meant significant backend rework, so a parallel implementation was the only way to ship and then compare the two honestly. That constraint is what made "keep both" the realistic answer rather than just the cautious one.
Why do Acknowledge, Suggest resolution steps and the rest live in the Copilot slider at all? Because they're conversational by nature. The slider is one centralised surface where an agent can ask a follow-up, refine, and re-ask, and the new pipeline supports multi-turn context, so suggestions update as the conversation evolves. The legacy single-turn generation could not do that. Instant insert belongs in the editor; anything you might want to argue with belongs in the slider. That's the line the regrouped menu draws.
Trade-offs
The thinking state we designed and then deleted
We built processing states, "Analyzing ticket context → Fetching solution articles → Reviewing historical cases → Drafting suggested reply", because transparency felt right. Then we realised that on the proactive path the text is pre-generated and inserted, not composed live. A spinner over already-finished work is theatre. It survives only where generation genuinely happens on page load, such as a non-assigned agent opening the ticket cold. Everywhere else it was cut.
The feedback control I lost on layout and fixed in focus order
Thumbs up/down stays in its original position rather than travelling with the accepted text, so feedback stays reachable after insertion, which is exactly when an agent knows whether the suggestion was any good. The cost was proximity: the controls sat visually disconnected from the thing they judged. We solved that in the tab order rather than the layout. After inserting a suggestion, Tab now moves focus to the feedback options instead of "Show quoted text," which was the previous next stop. The keyboard path makes the relationship the layout couldn't.
Inline citations we couldn't ship
The design called for numbered citations inside the suggested text, so an agent could hover a specific claim and see the article or past ticket behind it. Verification at the point of doubt. That wasn't technically possible in this release. Sources are appended at the end of the draft as links ("Check the following article(s) for more details"), which the requester also receives. It works, and it's weaker: the agent has to read the whole draft before they can check any part of it, and a claim in paragraph two can't be traced to its source. Getting verification back to claim level is the open item I'd carry into the next version.
Other things the design had to answer
Send is blocked while an unaccepted suggestion is sitting there, with a tooltip telling the agent to insert or dismiss. Nobody wants a silent half-written ghost draft going to a customer. And the edge cases were treated as product, not QA: editor out of viewport · existing drafts · cursor-position insertion · delayed generation · a newer suggestion arriving before the old one is dismissed · refinement while a suggestion is live · translation preview including the suggested text · selected-text handoff to Copilot · abuse reporting.
Control
What stayed human
Agents decide whether to use the suggestion, whether the pre-selected intent fits, which alternative reply type to request, which knowledge sources inform it, how it's edited, and whether the output was helpful, inaccurate, outdated, unclear or harmful.
This is not an autonomous sending system, and the design makes that structurally true rather than promising it in copy.
Results
The target was 70% acceptance. We're at 7%.
Product analytics, August and September 2026. September is a partial month through the pull date, so its growth is understated.
| Funnel stage | Aug | Sep | Sep vs Aug |
|---|---|---|---|
| Suggestions generated | 117,352 | 323,779 | 2.8× |
| Seen by an agent | 17,647 · 15.0% of generated | 54,226 · 16.7% | 3.1× |
| Inserted | 1,210 · 6.9% of seen | 3,941 · 7.3% of seen | 3.3× |
| Dismissed | 13,821 · 78.3% of seen | 42,678 · 78.7% of seen | 3.1× |
| Left sitting, no action | 2,616 · 14.8% of seen | 7,607 · 14.0% of seen | 2.9× |
| Inserted, as % of everything generated | 1.0% | 1.2% |
Reading it honestly
We are nowhere near the 70% target. Acceptance among suggestions actually seen moved from 6.9% to 7.3% while volume tripled. A 0.4-point rise is not a win. What it is is evidence that quality held under 2.8× the load. The system didn't degrade as it scaled, which is the weaker claim I can actually defend.
84% of what we generate is never seen by anyone. Suggestions fire on qualifying ticket events whether or not an agent opens the ticket or the reply editor. That's compute spent on nothing, and it says the trigger set is too broad. It's the strongest, cheapest fix available, and it isn't a UI fix.
The 78% dismissal number is partly my own design decision showing up as data. I made removal plural on purpose: typing anything clears the suggestion. The instrumentation inherited that. So remove_suggestion fires identically whether an agent read the draft and rejected it, or simply started writing their own reply without looking. Those are completely different failures and the event can't tell them apart. The semantic-similarity metric I argued for, comparing what the agent actually sent against what we suggested, was designed to separate exactly these two cases, and it isn't instrumented yet. Until it is, the dismissal rate is unreadable, and I'm the reason it's unreadable.
Caveat on the comparison: August and September are different populations. The rollout was still ramping, so this is a growing cohort, not a controlled before/after.
Reflection
What I'd do differently
I'd have instrumented the difference between "rejected" and "started typing" before launch. This is the real miss. I designed a dismissal model with four distinct paths and let it ship behind one event. The consequence is that the headline adoption number can't be diagnosed. I can tell you it's 7%, and I cannot yet tell you why. Designing the interaction and not designing its telemetry is half a job.
I'd have pushed on the trigger set, not the interface. Five months of my attention went to the 16% of suggestions an agent sees. The 84% they never see was a product-rules problem I treated as someone else's.
I'd have fixed the vocabulary in week one. "AI suggestion," "reply suggestion" and "smart reply" all appear across the PRD, the designs and the UI. Four teams, three names, one feature. It compounds into support articles, analytics event names and customer confusion.
I'd have asked engineering the pipeline question earlier. I spent time designing around the assumption that the new context could be retrofitted into the existing AI options. Once I understood the data sources and API shape made that impractical, "keep both and phase out later" stopped being a hedge and became the only honest plan.
Next proof point: separate real rejection from passive dismissal, then narrow the triggers. Until those two land, every conversation about this feature's adoption is a conversation about a number nobody can explain, including me.