Case study
Fixhos: an AI ticket desk for short-term rental hosts
Guest requests arrive by email, WhatsApp, voice message, Airbnb and Booking.com. An AI reads each one, files it, ranks its urgency, drafts the reply in the guest's own language and routes the job to the right trade out of 56. Live, in Early Access.
My role
This one is mine, not a client's. I am a co-founder of Fixhos and I write the code. Nobody commissioned it and nobody signed it off, so read it as what I can build and run, not as a delivery someone paid for.
The situation
A short-term rental manager's day is the same fifty messages: the wifi code, a late checkout, a boiler that died at eleven at night, a cleaning that has to move. They land in five different places, in whatever language the guest speaks, and every single one has to be read, understood, answered, and half the time handed to somebody with a van.
The constraint
The intake is not one channel, it is five, and two of them are not really channels at all. Email and WhatsApp are real inboxes. Voice is a phone number that answers, records and transcribes. Airbnb and Booking.com hand you no API for guest messages: they send a notification email, so the system has to recognise the platform from the mail itself and put the conversation back together as one thread. All five have to end up as the same object, or nothing downstream works.
The AI has to be allowed to be wrong without anyone paying for it. A model that files a gas smell as housekeeping, or that invents a check-in time it does not know, does damage no dashboard undoes. So the model never gets the last word on its own: a draft that is about to send itself goes through a second grounding check first, a high-stakes ticket gets a second and stronger pass, and a shadow mode runs the entire pipeline while sending nothing at all, so a new hotel can watch what the system would have done before it lets it do anything.
And it has to work in the guest's language, not the host's. The interface ships in four; the guest writes in whichever one they feel like, and the answer has to come back in that same one, from a property that may not speak it.
What I built
Fixhos is live at fixhos.com and in Early Access, so what follows is what the product does. There is no adoption figure on this page and that is deliberate.
- Five intake channels feeding one ticket: email (Gmail, Outlook and Zoho over OAuth, plus a signature-verified inbound webhook), WhatsApp on both the Meta Cloud API and Twilio, a phone number that answers and records, and Airbnb and Booking.com recognised out of their own notification emails and merged back into a single thread.
- One AI pass that returns the whole judgement in a single call: the category out of 15, the urgency out of 7 severity levels, a one-line summary written in the guest's language, the language itself, whether it is a life-safety matter, and which trade should take it out of a 56-role taxonomy.
- A drafted reply grounded on the property's own documents and on answers a human has already validated, then checked by a second model call against those same facts before anything is allowed to send itself.
- Dispatch to the people who actually do the work: role matching, an offer a technician accepts or declines from Telegram, response targets from 30 minutes to 72 hours, and escalation when one is missed.
- Eight separate AI jobs (classify, draft, translate, extract, analyse an edit, onboard a vendor, verify a draft, transcribe a voice note), each pointed at its own model by configuration and each logged with its token cost, so changing model is a setting and not a rewrite.
- A shadow mode that runs everything and sends nothing, plus a plain keyword classifier scored against the AI's own decisions, so the quality of the automation is measured instead of assumed.
- Four interface languages (English, French, Spanish, Italian) and a mobile app for the people in the field.
- 181 API routes and 307 test files behind it, on a promotion gate: nothing reaches production until the type check, the linter and the test suite have passed on the branch below.
The numbers
- 5intake channels, one ticket
- 56trades in the routing taxonomy
- 15ticket categories, 7 severities
- 4interface languages
- 181API routes
- 4,475automated test cases
Every number here is counted from the repository itself: the channel and category types, the role taxonomy, the language list, the route files and the test declarations. There is no customer count, no ticket volume and no time saved, because the product is in Early Access and I will not publish a figure I cannot show you the source of. The claims on the product's own marketing site are its own; only what is in the code is on this page.
What this is, and what it is not
Fixhos is my own company. I am a co-founder and I am the developer, which is exactly why it is the weakest kind of proof for one thing and the strongest for another. It is not proof that a client approved my work, because there was no client. It is proof of what I can put into production and keep running: a live multi-channel AI system with real phone numbers, real money and real people on the other end of it.
It is in Early Access, and the first hotels are onboarding. That is the reason there is no usage number above. I would rather show you the shape of the system than a metric you have no way to check.
What I would do differently: I let the intake grow to five channels before the shadow mode existed. Building the way to measure the automation after the automation is the wrong order, and the plain keyword classifier that now scores every AI decision would have cost an afternoon on day one. It cost considerably more to retrofit.
Stack
- Next.js
- React.js
- TypeScript
- Anthropic Claude
- Google Gemini
- WhatsApp Business API
- Twilio
- Firebase
- Stripe
- Tailwind CSS
See it
Want something like this?
Tell me what you are building, or what you are still doing by hand, and I will tell you how I would approach it. No commitment.