Le Marquier makes plancha grills and outdoor cooking equipment in Came, in the French Basque country. Their products run from around 500 EUR for an entry-level plancha to over 4,000 EUR for a custom outdoor kitchen, and they sell into France, the United Kingdom, the United States and Italy. Roughly 60% of inbound support arrives in French; the rest splits across English and Italian.
The support team is one to three people at headquarters, fluent in French, with varying English and limited Italian. They answered the phone from 9:00 to 17:30, Monday to Friday, which means an American customer standing over a grill on a Saturday afternoon had nobody to call. At peak grilling season hold times stretched past fifteen minutes, and the annual support bill sat around 70,000 EUR and kept climbing.
We built them a voice agent. It now handles their support line, and the numbers are in the full case study with results. This post is the other half: what I actually learned building it, written for anyone about to do the same thing.
1. Language switching is a routing decision, not a feature you turn on
The instinct is to treat multilingual support as three agents behind a menu. Press 1 for French, press 2 for English. That is how phone systems have worked for thirty years, and it is the wrong shape for a premium brand, because the menu is the first thing a caller experiences and it tells them they are talking to a machine before anyone has said a word.
What we did instead was detect the language from the caller's first few seconds of speech and answer in it. No menu, no selection step. The design consequence is larger than it sounds: language stops being a branch at the top of the call tree and becomes a property that travels with the conversation, which means every downstream step — the knowledge lookup, the escalation, the callback message — has to carry it too.
The second decision was not to maintain three knowledge bases. Le Marquier's product documentation is written in French, and that stays the single source. The agent reads French and answers in whatever language the caller is speaking. Three parallel knowledge bases would have meant three sets of edits every time a product spec changed, and in practice one of the three always falls behind.
The part worth budgeting time for is testing. Native speakers, not translated scripts, calling with realistic problems: heavy accents, a noisy workshop, and above all code-switching — a French customer dropping an English product name mid-sentence, which happens constantly with technical vocabulary. That is where a multilingual agent breaks, and you will not find it by reading transcripts of your own test calls.
2. On a premium brand, the voice is the product
Le Marquier's customers are spending four figures on an object that will sit in their garden for fifteen years. They have already decided this is a company that cares about craft. A voice agent that sounds like an airline hold system contradicts that in about two seconds, and no amount of correct answers recovers it.
So the voice selection was not a settings dropdown we filled in at the end. It was scoped alongside the conversation design: warm, knowledgeable, unmistakably French rather than a French-accented generic. For the English and Italian markets, the same exercise again rather than a single voice stretched across three languages.
What I would tell anyone starting this: judge candidate voices on your own product vocabulary, not on the vendor's demo sentences. Plancha, inox, fonte, brûleur — the words that decide whether a caller believes the thing on the other end knows the product are exactly the words a generic demo never contains. A voice that reads marketing copy beautifully can still mangle the one term your customers say in every call.
3. Escalation is a product decision, and it belongs in the design, not the fallback
Every voice agent escalates. The question is whether that path was designed or whether it is where calls go when nothing else matched.
We wrote the escalation rules before the happy paths: hand off after two failed attempts at the same question, immediately when the caller asks for a person, and immediately on anything that reads as a complaint or a safety concern. Gas appliances make that last one non-negotiable. Outside office hours, when there is nobody to hand off to, the agent takes a detailed message and books a callback rather than looping.
The detail that mattered most was what travels with the handoff. An escalated call arrives at a human with the transcript attached, so the person picks up where the agent stopped instead of opening with "can you explain the problem again?" A caller who has already described a warranty issue twice and is asked a third time has had a worse experience than if they had waited fifteen minutes on hold. Escalation rate is the visible metric; escalation quality is the one customers feel.
4. Warranty and parts questions are where the agent earns its place
Before building anything we went through six months of call recordings and sorted them by type. The top fifty call types covered about 90% of the volume, and the shape of that list is consistent with what I have seen at other specialty brands: product care and seasoning, warranty terms, spare parts, dealer locations, order status. Repetitive, factual, and with answers that do not change.
Warranty is the one worth pulling out. Handled manually, a single claim runs ten to fifteen minutes on the phone collecting details, then back-and-forth email asking for photos of the defect, then manual entry into a tracker, then internal routing to a technical assessor, then follow-up with the customer. Thirty to forty-five minutes of staff effort spread across three to five days, for a process that is almost entirely structured data collection.
That is the work to automate first, and not because it is the most frequent. It is because a human adds nothing to the collection step and everything to the judgement step, and a voice agent separates the two cleanly. The agent gathers product, purchase date and description of the fault, then hands a complete record to someone whose time is worth spending on the actual decision.
The general rule I took away: rank candidate call types by how much of the interaction is data collection rather than judgement, not by how often they occur. A high-frequency call that needs judgement in the middle is a worse first target than a mid-frequency call that is pure intake.
5. Measure cost per resolved call, not minutes
Minutes are what vendors bill on, so minutes are what everyone tracks. They are a poor way to judge whether the thing is working. An agent that talks for four minutes and resolves the question is better than one that talks for ninety seconds and escalates, and a per-minute view scores it worse.
The number I care about is annual support cost divided by calls actually resolved. It absorbs the things a minutes view hides: escalation rate, repeat callers who did not get an answer the first time, and the after-hours calls that previously did not happen at all because nobody was there. It also makes the comparison honest, because the before-state has a cost per resolved call too, and it is usually never been calculated.
For Le Marquier the annual support cost went from about 70,000 EUR to about 14,000 EUR, on roughly 2,500 minutes of agent conversation a month and a 98% resolution rate. I am quoting those from the case study rather than re-deriving them here. The point for anyone budgeting a build is the denominator, not the figures: decide what counts as resolved before you go live, because deciding afterwards is how projects end up arguing about their own results.
What I would tell myself at the start
Three things. Write the escalation rules first — they constrain the conversation design far more than the other way round, and retrofitting them is painful. Pick the voice against your own product vocabulary rather than the vendor's script. And agree the success metric before the first call is answered, because after launch every number becomes an argument.
The eight-week timeline in the case study is real, but it was only achievable because the discovery phase was six months of recordings rather than a workshop. The tempting shortcut is to skip that and design from what the team believes the calls are about. Every time I have seen someone take it, the first month live is spent discovering the call types nobody mentioned.
