Keep the FAQ and help pages in step with what customers actually ask
Compares recent tickets with your help pages, finds questions with no good answer online, and drafts FAQ updates from your agents' best real replies.
- How it works
- A batch job compares recent support tickets against your existing help content: which frequently asked questions have no good page, and which pages say something different from what your agents actually wrote back. Where your helpdesk records it, it can also flag pages customers saw but still wrote in about — a sign the page is unclear. It then drafts new or revised FAQ entries based on the best real agent answers, for an editor to approve.
- Data you need
- Resolved tickets or support email threads including the agent replies, plus your current help-centre content. The agent replies are the gold — they contain the answers your docs are missing. A shared support inbox is enough; phone-only support with no transcripts gives it nothing to work with. The "viewed the page but still escalated" signal only works if your helpdesk links page views to tickets — many SMB setups do not, and the rest works without it.
- What to expect
- It reliably surfaces the gap between what customers ask and what your pages say, and the drafts start from answers your own team actually gave. The model proposes; it cannot judge whether an answer was correct or just what one agent said once, so garbage tickets in means garbage FAQ out — curate which threads feed it. Drafted text can embed a one-off concession as if it were policy and can carry customer details from real replies; both must be caught in review. Tickets contain personal data: processing stays on EU-resident hardware, but anything published must still be scrubbed.
- Where people stay involved
- An editor approves every published change. Watch for one-off agent concessions dressed up as policy, and strip customer names and order numbers before anything goes public. Legal-adjacent pages — returns, warranty, GDPR notices — need the same review as any policy edit.
Which model, and what it costs to run
Qwen3-8B
This job runs in bulk rather than to a waiting person, so size is not the constraint — we take the strongest independent score on sticking to the document that we may serve freely and that fits on a single card.
- Licence
- Apache-2.0
- Weights at 4-bit
- 5 GB
- Context
- 32K tokens
- Publisher
- Alibaba (Qwen Team)
What the hardware costs
One 48 GB card holds it
- Rent in the EU
- $1.60/hrScaleway, Paris (PAR2)
- Buy the card
- $7,569new, one-off
- Or rent it by the token
- $0.04 / $0.04per M in / out · DeepInfra
Hardware only, third-party prices from 2026-07. The figure excludes the KV cache, which grows with context length and how many people use it at once — sized properly in a conversation, not guessed here. Renting by the token is cheaper up front; why our customers still self-host is below.
Sticking to the document
Measured on public documents, by a model acting as judge. Read it beside the answer rate: the lowest hallucination rates on this board belong to models that simply decline more often.
Independent measurement · Vectara · board updated May 11, 2026
Structured output and tool calls
Measured in a sandbox, on somebody else's functions. It tells you which models are capable of the shape of the job, not which one will survive contact with your API.
Independent measurement · UC Berkeley (Gorilla project) · board updated 2026-04-12
The API is cheaper per token. Here is why our customers don't use it.
We will not pretend otherwise: renting a model by the token from a serverless API costs less per million tokens than a card we run for you. We show that price on every use-case page. What it does not include is the part a shop with a customer database actually pays for.
- 01
Your data never leaves hardware you can point at
A serverless "we don't retain your data" is a clause in a contract. Running the model on a card in Amsterdam is a fact of architecture: your catalogue, tickets and customer records are never sent to a third party at all. For a GDPR audit, that is the difference between a promise and a floor plan.
- 02
The price cannot move without your say-so
A serverless rate card is somebody else's lever. The provider can raise the price, retire the model, or change the terms, and your cost moves with it. The same model on the same card costs the same next year — you own the number.
- 03
The model cannot be taken away
Hosted APIs deprecate models on their own schedule; the one you built on can be gone in a quarter. An open-weight model on your own hardware runs for as long as you keep the lights on. No vendor can end-of-life it out from under you.
And the price gap closes with volume: past a card you keep busy — very roughly four billion tokens a month — owning is cheaper outright, even before the three reasons above.
Getting a case like this one from a conversation to production takes about two months, and you can stop at the end of any phase.
Also in customer service
All 15 →Sort the support inbox before anyone reads it
Classifies every incoming message into your own categories, pulls out order details, and routes it to the right queue before anyone opens it.
Draft answers to where-is-my-order emails
Looks up the real order and tracking status and drafts a reply with the carrier's information, ready for an agent to approve and send.
Suggest replies from your own help pages and policies
Finds the relevant passages in your FAQ and policy pages and drafts a reply based only on them, with a link to the source for the agent to check.
Handle return and refund requests against your own policy
Checks a return request against your written returns policy and drafts the instructions or a polite refusal, for a human to approve.
Next
Tell us what your team does by hand
Describe the process that takes the most time. We will say plainly whether a model is the right tool for it.