Introduction
Even if the AI produces good drafts, it means nothing if operators find them hard to use. The moment someone thinks "it's faster to write it myself than to fix the AI's draft," the system stops being used.
That's exactly why the operational design — how the draft is delivered, reviewed, and sent — decides whether the system succeeds. This article explains the approval flow and operator-experience design that let people use AI drafts with confidence.
Where to Put the Draft
Attach as a note, don't send an email
The generated draft is not sent as an email to the customer — it's attached to the HubSpot ticket as a note (internal memo). When an operator opens the ticket, the draft is waiting there.
This extra step matters: it clearly separates "the AI's proposal" from "the email actually sent." As long as it's a note, it never reaches the customer's eyes, so operators can edit it freely. The final send is done by the operator's own action, while looking at the draft.
Guarantee "humans send" by design
There's also a design decision to not give the system an email-sending capability at all. Make it technically impossible to send, and "oops, it auto-sent" accidents structurally cannot happen.
Human-in-the-loop (a design that always involves a person) always frays if you try to enforce it with operational rules. Limiting the sending path to humans as a mechanism is the reliable way.
Misdeliveries and incorrect guidance reach the customer instantly. Human involvement relies on operational rules and frays easily
A human always checks before it reaches the customer. The sending path is limited to humans, so accidents can't structurally occur
The Form of a Review-Friendly Draft
Prioritize "easy to fix"
The ideal draft isn't perfect prose but prose that's easy to fix. Even if it's a bit plain, as long as the facts are accurate and the structure is sound, an operator can turn it into their own words in seconds. Conversely, a draft packed with fancy phrasing takes time to judge where to fix.
So drafts are designed to be plain, easy-to-follow text without excess decoration — leaving room for a human to add the final "seasoning."
Add grounds to aid verification
The first thing an operator wants to check is "is this draft's content correct?" So the draft includes information in a form where the grounds — the referenced order info and past tickets — are visible.
If it says "the △△ ordered on [date]," the operator can verify facts on the spot without reopening the order-management system. Reducing verification round-trips directly shortens review time.
Flag low-confidence parts honestly
Where the AI isn't confident — when product-name matching is ambiguous, or when several orders could apply — it doesn't force an assertion but leaves it in a form where "needs checking" is visible. Being told honestly beats a confident assertion that hides the uncertainty, and it lets operators review with peace of mind.
Review-friendliness builds trust
When the draft's grounds and uncertain points are visible, operators shift from "using AI while doubting it" to "sharing the work with AI." This sense of trust is the dividing line for whether the system keeps getting used.
The Design Behind the Scenes
Async processing and re-runs
Draft generation is processed asynchronously through a queue service called QStash. Because AI generation can take time, the design reliably processes tickets in order once received.
Tickets that fail to process, or that you want to regenerate, can be re-run from the admin screen. Having a manual escape hatch to remake a draft "when a good one didn't come out" makes a world of difference to operational confidence.
Verification and control on the admin screen
The admin screen shows a list of target tickets and their processing status. You can grasp which tickets got a draft, which are unprocessed, and which failed, and re-run individually as needed.
Rather than making it a fully automated black box, leaving room for operators to see the situation and step in really pays off in production.
Process periodically-fetched new tickets via QStash
Add a context- and intent-aware draft to the ticket note
Verify the grounds and edit as needed
The operator confirms the final text and sends
Regenerate from the admin screen if the draft is insufficient
Conclusion
The key to putting AI drafts into production lies not only in generation accuracy but in operational design that lets people use them with confidence.
- Attach drafts as notes and limit the sending path to humans, preventing accidents structurally
- Prioritize "easy to fix" and "visible grounds" over perfection
- Flag low-confidence parts honestly, building a sense of sharing the work with AI
- Leave room for operators to step in via async processing, re-runs, and the admin screen
This operational design comes alive precisely because of Injecting Customer Context and Classifying Intent. The aim of the whole mechanism is covered in the hub article — please read them together.