We design AI chatbots and virtual assistants around a real service: the questions people ask, the knowledge they can trust, the tasks they need to complete, and the moment a person should take over.
“Can I change where this order is delivered?”
Customer · authenticated account · webAddress changes are available before dispatch.
Current order state checked · confirmation required
The right conversational system depends on the job: guide a known path, explain governed knowledge, resolve a service request, or connect several parts of a journey.
Best when the available paths are known in advance. People choose from clear options and the experience leads them to the right information or form.
questions vary widely or depend on account context
Best when people need to ask natural-language questions across a controlled set of company information. It finds and explains; the person decides what to do next.
the request requires a transaction or a sensitive service decision
Best when customers need answers, guided resolution, and a small set of clearly bounded actions inside a support journey.
the conversation depends on judgement, negotiation, or open-ended advice
Best when the conversation spans several related tasks, remembers permitted context, and coordinates between knowledge, systems, and human support.
a focused chatbot or simpler interface already resolves the need
These modes can sit on the same technical foundation. The difference is the service promise made to the person using it—and the route available when that promise cannot be met.
The same conversational pattern behaves differently for a customer seeking resolution, an employee finding policy, and a buyer choosing a service. We design around that context.
Questions begin with an immediate need: find an answer, understand an option, or fix something without losing the route to support.
Answer recurring questions, retrieve permitted account context, and route exceptions to the right service team.
Explain relevant features, options, and service differences without disguising the limits of the guidance.
Walk people through requirements, collect the next useful detail, and surface blockers early.
The assistant helps people navigate company knowledge and routine services while keeping personal or restricted cases with authorised teams.
Find current procedures, policies, and operational guidance across governed company sources.
Guide routine HR, IT, workplace, and access requests with an explicit exception route.
Conversation supports a decision or prepares the next human interaction; it should never manufacture fit or make an unowned commitment.
Ask useful questions, explain the offer, and route a suitable enquiry with its context intact.
Find availability, explain prerequisites, and prepare a booking or service request.
Provide a consistent first layer of guidance with a route to appropriately skilled human support.
A reliable conversation connects three fields: what enters, what governs the response, and what leaves. A gap in any one of them becomes visible to the person as a weak answer or a broken handoff.
The assistant operates inside these fields. Missing context narrows the answer; it does not invite invention.
Clear explanation, bounded by the source
A guided action or confirmation
Owner, reason, and conversation context
The lime field is not “AI confidence.” It marks the service contract: the assistant can explain this answer and the user still has a clear next route.
The assistant has enough governed context to explain the answer and offer the appropriate next step.
Why this answer · source context · next step
The assistant asks only for information the service path needs, and explains why that detail matters.
What is missing · why it is needed
The request needs judgement, authorisation, or support beyond the assistant's defined boundaries.
Who takes over · what transfers · what happens next
Website · product interface · messaging · support portal · mobile
Anonymous visitor · authenticated customer · employee · account role
Conversation design · retrieval · interface · action logic · handoff
Policies · product data · help content · CRM · orders · account state
Support desk · live chat · scheduling · workflow · authorised teams
The specific connections depend on your systems, permissions, identity model, and the interfaces they expose. This map describes the service architecture, not named technology partnerships.
A menu, not a checklist. Final scope depends on the audience, questions, channels, knowledge, and actions involved—no engagement includes all of it.
Five stages for a useful assistant. Its role, sources, boundaries, and handoff model are defined before the full experience is built.
Understand the request, ground the guidance, then resolve the next step or route it to a person. The lime station marks the resolution point.
Illustrative service pattern, not a client case study or performance claim.
The controls around an assistant, grouped by what they govern. These are design decisions agreed with your security, legal, service, and operations teams—not guarantees of accuracy, security, or compliance.
Working answers. Scope, timing and commitments are agreed per engagement, in writing.
A chatbot usually handles a focused set of conversational journeys. A virtual assistant often spans several related tasks, uses more context, and connects across knowledge and service systems. The label matters less than defining exactly what the experience may answer, do, and hand over.
Usually, if the relevant information can be prepared as governed sources with clear ownership and permissions. We design how information is retrieved, how changing content is updated, and what happens when sources are missing or disagree.
Often through the interfaces those systems already expose, under their existing access rules. We scope the specific records, actions, identity requirements, and fallback path before committing to an integration.
By constraining the assistant to governed sources, testing representative and difficult questions, defining answer and refusal boundaries, and monitoring source gaps after launch. These measures reduce risk; they do not create a guarantee that every response will be correct.
Yes. The handoff route is designed as part of the core experience: when it appears, what context transfers, which team receives it, and what the user sees while that transition happens.
Potentially, when the source content, service model, quality review, and human-support coverage exist for those languages. We scope language by language rather than assuming one configuration performs equally everywhere.
That is usually the clearest way to begin—one audience, question set, channel, or service journey, with the source and handoff model tested before the experience widens.
Unresolved questions, user feedback, handoff reasons, source gaps, and evaluation scenarios are reviewed against the criteria agreed during design. Someone in your organisation needs to own the live service and its content; we define that operating model during handover.
Show us the questions people ask, the information they need, and the point where a person should step in. We will help determine whether an assistant—or a simpler experience—is the right answer.
studio@quirkydock.com · working internationally · CET
