GataTot
An AI concierge on WhatsApp that turns a few plain words into a job a tradesperson can price.
GataTot is a home services platform for Bucharest and Ilfov. We built its intake layer: an AI concierge that meets people in WhatsApp, where they already are, and lets them ask for help the way they actually ask - in their own words, in Romanian or English. The assistant asks only for what is still missing, works out which trade the job belongs to, and produces a structured request an operator can review and a tradesperson can price. Everything after it - matching, review, distribution, payment - is built around that one clean request.
Where the AI Earns Its Place
Understands the Request
A sentence in plain words becomes a structured, priceable job. No category dropdown, no form.
Confirms Before It Commits
The request is read back and corrected in the chat. Nothing is created until the customer says yes.
Knows Its Limits
Anything that has to hold - contact details, urgency, permissions - is enforced in code, not in a prompt.
The Challenge
Asking for a tradesperson has always meant a phone call, or a form that asks you to pick a category you have no way of picking correctly. Is a wobbling table a carpenter, a handyman, or furniture assembly? People do not know, and they should not have to. What they do instead is describe the problem in their own words - "my table wobbles", "the socket sparks". On the other side, tradespeople pay for leads that arrive vague, mislabelled, or outside the area they actually cover. The job was to take a request the way a person naturally gives it and turn it into something a professional can quote against.
What We Did
Made the Chat the Front Door
Intake happens in WhatsApp and on the web, in Romanian or English. The assistant asks only for what is still missing, confirms what it understood, and produces a structured request - trade, location, urgency, description - without the customer ever seeing a form.
Nothing Exists Until It Is Confirmed
The conversation builds a request in the open and creates nothing while it does. The customer sees the trade, the address, the timing and the description read back to them, changes whatever is wrong by saying so, and only then does a request exist. It is also why the assistant can be wrong safely: being corrected is part of the flow rather than an error state.
Classified the Work, Then Tested the Classification
Turning free text into a trade is where this quietly goes wrong. "Repair a table" and "fix my table" were landing in two different trades, because generic verbs had been attached to specific ones as keywords. Classification is now covered by tests that fail if two trades claim the same keyword, or if a generic verb is claimed at all.
Put the Boundaries Where the Model Cannot Move Them
The job description is shown before payment, and people write their phone number into it. The assistant avoids repeating it, and does that well, but a model is not a boundary: contact details are stripped in code, where nothing can talk them out of it. Urgency is handled the same way - asked as a date, somebody has to come today, rather than as a feeling.
Matched, Reviewed and Unlocked
Requests are matched to tradespeople by trade, service area and distance, reviewed by an operator, and distributed. A professional sees the job before paying and unlocks the contact afterwards. Every role - customer, tradesperson, operator, administrator - is authenticated, and the whole flow is covered by an automated test suite.
The Outcome
The whole loop is built and working end to end: a customer describes a job in a few words, the assistant turns it into a structured request, an operator reviews it and sends it to up to three matched tradespeople, and the one who pays unlocks the contact.
Screens
