Let AI draft.
Let a person send.
For a shop owner, the useful outcome is less time answering repetitive messages. A fully autonomous support agent adds risk before you know whether the drafts are any good.
Start by reducing the time it takes to produce a correct reply. Keep sending, refunds, and exceptions under human control.
First question to test: can someone review and edit the draft faster than writing their usual response?
Build around one useful task.
Sort an incoming message
AI usefulSupportingRecognise the customer’s intent from different wording. Start with a few categories and let the reviewer correct a label. Test mixed requests and ambiguous language.
Draft a reply from approved information
AI usefulCriticalUse the shop’s policy and a message to draft a reply. An experienced developer should review how the system limits unsupported claims and separates instructions from customer text.
Review and send
Plain softwareCriticalShow the original message beside an editable draft. A person approves every reply. Clear state and duplicate-send protection matter more than AI here.
Approve a refund
Keep humanLeave out initiallyLet the existing shop workflow handle money. Payment permissions and financial actions need specialist attention before automation.
Try the existing inbox first.
Compare three routes before building the full workflow. Specific vendors and current pricing would need to be checked against your requirements.
An existing help desk with AI drafting
Potential coverage: shared inbox, draft replies, approval, and sending. Test whether its shop integration and policy controls are sufficient. The trade-off is ongoing per-seat or usage fees.
Your current inbox plus a draft assistant
Potential coverage: drafting, while review and sending stay in the current tool. Less migration, but the hand-off could erase the time saved.
A custom support product
Potential coverage: a tailored workflow and stronger differentiation. You also own reliability, permissions, support, and integration maintenance.
Would small shops prefer a simpler approval workflow to a feature-heavy help desk? Watch an owner use both before choosing that positioning.
Make the assumptions visible.
Illustrative assumptions: 100 drafted replies per active user each month; $0.01 of AI usage per reply; other monthly costs of $50, $200, and $1,000 at the three scales. These are planning inputs, not vendor prices.
| Active users | AI / month | Other / month | Total / month |
|---|---|---|---|
| 100 | $100 | $50 | $150 |
| 1,000 | $1,000 | $200 | $1,200 |
| 10,000 | $10,000 | $1,000 | $11,000 |
Double the replies per user and AI spend doubles. Put a usage allowance in the first pricing experiment and measure actual consumption.
These totals exclude wages, taxes, refunds, customer acquisition, and payment fees. Test willingness to pay and actual costs before setting a price.
One inbox. One clear test.
Build first
- Paste a message and select an approved policy.
- Generate an editable draft.
- Record whether the draft helped.
Leave out for now
- Automatic sending and refunds.
- Multiple inbox integrations.
- Advanced analytics and team roles.
With five shop owners, compare 20 anonymised messages each. Aim for at least 70% of drafts to need only minor edits, with a lower median handling time than their current method and no unsupported policy promises.
The threshold is an experiment choice. Ask whether owners want to continue using the assistant after the test; a good accuracy score alone does not prove demand.
Resolve these before real data.
- Data access: identify whose messages are used, what permission is needed, and who may see the output.
- Data handling: review the chosen provider’s retention and processing terms with an appropriate adviser.
- Customer impact: keep refunds, policy exceptions, and sending under human approval for the pilot.
These are review prompts for this example, not a determination of legal compliance.
Give the first version a clear brief.
- Ask five shop owners to show you the last repetitive support conversation they handled.
- Build a consented, anonymised test set and agree on what counts as a correct reply.
- Try an existing tool on that set before deciding to build.
- If a custom prototype is still justified, use the brief below.
- Compare handling time, edits, and unsupported claims; decide what to change before a second pilot.
Build a prototype for a shop owner to paste a customer message and an approved shop policy. Show an AI-generated draft next to the original message and let the owner edit it. Do not connect to an inbox, send messages, or issue refunds. Add a way to mark whether the draft helped and how much editing it needed. When the supplied policy does not answer the question, ask the reviewer to fill the gap instead of inventing a promise. Start with synthetic test messages.
Be ready for the useful objections.
Why not just paste the email into a chatbot?
That may be enough for an early experiment. The custom product needs to prove that its approved policy, review workflow, and reduced copying create additional value.
What if the draft is confidently wrong?
Human review remains mandatory. Test for unsupported promises explicitly and make the relevant policy easy to inspect beside the draft.
What would make you stop building?
If existing tools solve the problem well, drafts take longer to review than to write, or shop owners do not want to continue after the pilot, revisit the product before expanding it.