Taskora Booking Assistant
A full scope from problem to booking (diagnose → match trade → book slot) chat bot.
The conversation flow — happy path down the centre, with every recovery branch looping back rather than dead-ending.
Taskora is a marketplace for booking home-maintenance technicians. This project designs a conversational booking assistant that lets someone describe a household problem in plain language and reach a confirmed appointment, without first having to work out which trade they need. The design goes deep where most conversation-design work stays shallow: dialogue logic and error recovery. The assistant's real job is translating a fuzzy human problem description into a structured booking and recovering gracefully when that translation goes wrong.
The conventional way to book a technician is category-and-filter: pick a trade, browse providers, book. That works only when the user already knows what they need, and home problems rarely present that cleanly. People describe symptoms, not services. Someone sees a damp patch spreading on a ceiling; they don't know whether that's a plumber or a roofer. Forcing them to self-diagnose into a category is a real point of drop-off and mis-bookings — the wrong trade arrives, the job can't be done, everyone loses time. The user is a homeowner or renter facing a problem they want fixed. They can describe what's wrong in everyday language but often can't name the right trade. They're typically on mobile, mildly stressed, and want reassurance they're booking the right person.
Conversation earns its place here for a specific reason: the input is fuzzy and needs interpreting. A dialogue can take “water's pooling under my kitchen sink,” ask one targeted question, and resolve it to the right trade and job type. A static filter UI handles this poorly because it assumes the user already knows the answer. My background in computational linguistics shaped this approach — the design treats trade selection as a disambiguation problem, resolving overlapping symptom descriptions before routing rather than asking the user to categorise themselves. Just as important is what was kept out of scope, each with a reason: emergencies and same-day dispatch (liability and real-time complexity), payment and pricing (a separate concern), and rescheduling or cancelling (a different task with its own flow — the assistant points users to it rather than faking it). A tight scope is what lets the flow go deep on diagnosis and error recovery instead of spreading thin.
A calm, competent dispatcher who's booked a thousand home repairs — efficient, reassuring, never dramatic.
Built as a Voiceflow agent, with the persona and two hard boundaries carried at the agent level. Two confirmation gates mean it never commits to a diagnosis or an appointment without echoing it back first.
Fig. 1 — Diagnosing a plumbing leak, then re-diagnosing to a roofer without restarting.
Four recovery branches are handled explicitly: vague description, wrong-trade correction, no slots, no response.
The interesting design isn't that the assistant got it right — it's that when it got it wrong, it recovered without making the user start over or feel foolish. In testing, it diagnosed a plumbing leak from a damp kitchen ceiling, then re-diagnosed to a roofer when the user mentioned cracked tiles and heavy rain: keeping everything it already knew, explaining the switch, and rejoining the flow at the same step rather than restarting. Both paths share one skeleton — capture, clarify, confirm, offer, confirm, book. Showing that structure survive a messy detour is the proof the flow is robust.
What I'd validate with real users first: whether one clarifying question is usually enough to disambiguate trades, or whether some problem types — damp, noises, smells — reliably need two. The diagnosis logic here is designed, not learned; real utterances would show where it's too confident.