Most of Fixlab's individual customers came in through WhatsApp, by text and voice note, and the customer-support team handled them alongside email, phone calls, and messages inside the platform. At first glance the questions looked involved. What documentation a certification needs depends on the exact modification and the specific vehicle, so a single conversation could branch through a lot of conditions: the year and model of the car, the type of reform, which photos and certificates apply, whether a given change is even viable.
Most of those questions, despite the branching, did not need an engineer's judgment. With a knowledge base structured well enough, you can tell a customer exactly what's required to change their headlights or add a tow bar: the year, the model, these documents, these photos. Gather it, file it as a reform request, and an engineer only has to verify and certify.
A minority of cases do need real judgment: converting a van into a camper with a bed, shelving, and a gas hob, or reading a photo to decide whether something can be certified at all. Those should reach a person. The high-volume, pattern-following majority should not have to.
Customer support fielded whatever came in through WhatsApp. A lot of it they could answer right away, often a simple “yes, you can go ahead, and you'll need XYZ,” and some of it needed a quick word with an engineer. It was rarely the hard part of the job, but the sheer volume pulled support away from the work where they add the most value. Replies could still take a day or more, longer in peak season and outside working hours, so customers chased across channels, often re-sending the same information and being asked for it twice. Support spent a large share of its time for a small share of the value, and customers finished the process less than satisfied even when the work itself was sound.
A WhatsApp front door that answers the answerable questions instantly, collects the right documentation, opens the reform request in the platform, and brings in a person only for the cases that genuinely need one. That frees the team to spend its judgment where judgment is actually required: complex reforms and premium clients.
Telegram was used during testing. In production, Fixi does four jobs, each one a thing the lab used to do by hand.
Fixi responds about vehicle certification using the lab's own criteria rather than generic guesses. The full knowledge base lives in the model's working context, so answers stay consistent instead of drifting.
When a customer is ready, Fixi identifies them against the Fixlab platform and opens a certification request directly through the platform's API, capturing the details the lab needs to act.
Customers often send photos and voice notes instead of tidy paragraphs. Fixi reads images and transcribes audio so the conversation flows, and groups rapid-fire messages into one coherent turn instead of replying to fragments.
When a case needs a person, Fixi escalates into the team's Slack with the full conversation attached as a clean transcript. The human takes over, the customer never notices a seam, and on resolution Fixi picks the conversation back up with context intact.
A messaging middleware sits in front and handles everything that isn't conversation. Behind it, an autonomous conversational agent runs the dialogue. Each does what it's good at.
We're not tied to one model. We use Claude (Sonnet and Opus), Gemini, and ChatGPT, leveraging each where it adds the most value. Certification conversations are dense with conditions and exceptions, and a single one can hinge on several at once, so choosing the right model for the work is what keeps answers correct instead of plausible-sounding. The model mix is part of the reliability story, not a stack flex.
If the agent doesn't respond in time, the customer gets an apology and the case is escalated to a person automatically. Network calls retry on transient failures.
The point was never a clever demo. It was something that holds up on a Monday morning, with real customers waiting.
We didn't ship and hope. Before going live, Odysi and Fixlab agreed on a written acceptance test: a Golden Dataset of 50 real scenarios covering customer identification, knowledge questions, full request creation, escalation, and resolution. The bar was explicit: zero critical failures and at least an 80 % pass rate.
The system went to production only after it cleared that bar, and after the full conversation cycle (escalation to a human and back) was validated end to end. That discipline is the point. A conversational system is easy to demo and hard to trust. Agreeing the test up front, in writing, with the client, is how you turn “it seems to work” into “it passed.”
Fixi passed its acceptance test and went live. The full architecture is validated across all five conversation paths, including the human handoff and resumption.
Because the system is newly launched, real-world usage data is still being gathered. We'll update this case study with field performance as it comes in, with real numbers rather than estimates.
Richer media handling in the human handoff.
Deeper enrichment of customer context from the platform.
Ongoing refinement of the core conversation logic as real usage reveals where it helps most.
A small product studio. We prototype, automate, and ship.
Small is the feature: you work directly with the people building the thing, and we care more about something that holds up in production than something that looks good in a pitch.