Request arrives
Every incoming message is picked up automatically, in French or English, with its history attached.
Automated
All case studies
Case Study — Support Automation
Safari Condo A support desk that answers before anyone types
A Québec motorhome and travel-trailer maker with more support requests than people to read them. We automated the desk: every request categorized and prioritized on arrival, and a reply already drafted from the company's own documentation, with a human still deciding what gets sent.
Engagement
From scratch
Where it runs
Inside the business
Auto-send
Never
Languages
EN / FR
Urgency levels
Four
Priority, urgent, moderate and low, assigned on arrival.
Request types
Five inboxes
Technical support, appointments, dealers, parts and federal recalls.
Every draft
Cites its sources
The agent can open each document the answer came from.
Auto-send
Never
Nothing reaches a customer without someone sending it.
The brief
The inbox was the bottleneck, not the answers
Safari Condo builds motorhomes and travel trailers in Québec. Its owners are on the road, and when something needs an answer they write in: about a system in the vehicle, a part, a service appointment, or a warranty question.
The answers almost always existed already: in the internal service documentation the team maintains, or in the public documentation owners have access to. What didn't exist was the time to find them, request by request, while the volume kept arriving.
- Request triage
- Priority ranking
- Documentation retrieval
- Pre-composed replies
- Bilingual EN/FR
What was actually at risk
Support automation usually fails by answering confidently and wrongly
A vehicle maker cannot afford a plausible-sounding answer about a propane system or a warranty term. So the risk we designed against wasn't slowness. It was a system that invents.
The usual support bot
How this one runs
Talks straight to the customer, unsupervised.
Talks to the agent. The agent talks to the customer.
Answers from whatever the model happens to know.
Answers only from the company's own documentation, quoted back.
Treats every message as equally urgent, first in and first out.
Ranks by category and urgency, so the road-side case surfaces first.
Leaks internal notes into customer-facing replies.
Internal and public sources kept separate. Internal informs the answer, public gets quoted.
Silently drifts as products, parts and policies change.
Re-indexes the documentation, and every draft names the source it used.
What we built
Five things happen before an agent reads the request
The desk the team already used stayed the desk. We put a layer underneath it that does the reading, sorting and drafting, so the first human action is a judgement rather than a search.
Categorized
It lands in the inbox it belongs to: technical support, appointments, dealers, parts or federal recalls.
AutomatedPrioritized
Urgency is scored, so someone stuck on the road doesn't sit behind a brochure request.
AutomatedReply pre-composed
The relevant passages are pulled from internal and public documentation, and a reply is drafted with the sources named.
AutomatedA person sends it
The agent reads, edits if needed, and sends. Nothing goes to a customer on the system's own authority.
HumanWhere the answers come from
Two documentation sets, one grounded reply
The company's knowledge was split: what the service team keeps for itself, and what owners are given. A useful answer needs both, but the two can't be treated the same way in front of a customer.
Internal
Service documentation
- Service procedures and known cases
- Parts and configuration detail
- Warranty terms and precedent
Public
Owner documentation
- Manuals and product guides
- Published FAQs and how-tos
- Anything an owner can already read
The guardrails
What the system is not allowed to do
Automation is only worth having if the failure modes are closed off first. These constraints were part of the spec, not an afterthought.
No answer without a source
Every draft is grounded in the company's documentation and names what it used. If the documentation doesn't cover it, the draft says so and routes it to a person instead of inventing.
No auto-send, ever
The system prepares; the team decides. Every customer-facing message is read and sent by a person, which is what makes the speed safe to use.
Internal stays internal
Internal service knowledge can shape a reply, but only public documentation is quoted to owners. The boundary is enforced in the retrieval layer, not left to prompt wording.
The path
Built against the real inbox, not a demo
We started from the requests the team had actually received, and measured every step against what a good agent would have replied. Technology second, intent first.
-
Read the desk as it is
Before anything was built- Real request history reviewed, not hypotheticals
- The categories the team actually works in
- What makes a request urgent, in their words
- Which answers already existed in writing
-
Make the documentation retrievable
Foundation- Internal and public sources ingested separately
- Access boundary encoded in retrieval
- Bilingual content handled as one corpus
- Re-indexing when documentation changes
-
Triage before drafting
First working slice- Categorization shipped and checked against real mail
- Priority scoring tuned with the team
- Misroutes reviewed weekly, rules adjusted
- Queue order visible to the agents
-
Drafts the team would actually send
Iteration- Drafts compared against replies agents had written
- Tone and structure set by the team, not the model
- Source citations required in every draft
- “I don't know” treated as a valid output
-
Handed over, still watched
In operation- Edits agents make tracked as the quality signal
- Categories and priorities revisited as volume shifts
- Documentation gaps reported back to the business
- Owned as a running system, not a delivered file
What the desk can now see
An operation the business can actually measure
A shared mailbox produces no numbers. Because every request now flows through a database, the team can look at the backlog by status and urgency, and at how long replies and resolutions are taking.
The result
Same team, same inbox, a different day
A support desk where the sorting, the ranking and the first draft are already done, and where every answer a customer receives was still chosen by a person.
For the customers
Faster first replies, and answers that match the documentation for their vehicle instead of a general guess.
For the team
No more searching two sets of documentation per request. The work that's left is the judgement, which is the part they're good at.
For the business
Volume absorbed without adding headcount, and a live map of what owners keep asking, which is a product signal as much as a support one.
Your turn
If your inbox is the bottleneck, this is the shape of the fix
Safari Condo is one case. The method is how we run every AI build: start from the real work, ground every answer, and keep a human on the send button.
Automate the work before the reply
Reading, sorting, ranking and retrieving are where the hours go. Automating those is safe, measurable, and usually enough.
Your documentation is the model's source
Answers come from what your business has written down, cited so anyone can check. That's what makes the output defensible.
Coherence, then speed
We check that the system does what you actually meant, and that it keeps doing it as products, parts and policies change.
Your desk, answering before anyone types
Tell us what lands in your inbox every day. We'll show you which part of it can be automated safely, and which part should stay human.