Services / AI / Assistants & chatbots

An assistant that answers instantly, at 3am, in any language

Most enquiries arrive when nobody is at a desk. An assistant built on your own documents answers them there and then (accurately, in your tone) and passes anything delicate to a person with the full conversation attached.

Why it matters

The cost is the wait

The expensive thing about customer questions is rarely the answer. It is the wait. A buyer with a sizing question at 11pm, a client chasing a delivery on a Sunday, a prospect comparing you against two competitors in the same browser session: every hour that passes makes the sale less likely and the support ticket more annoying. Hiring around the clock solves it and costs a fortune. Ignoring it quietly costs more.

A well-built assistant is not a decision tree with a friendly avatar. It reads your actual material (your product data, policies, manuals, past tickets) and answers from that, citing where the answer came from. When it does not know, it says so and fetches a human instead of improvising. That single behavioural difference is what separates an assistant customers trust from the ones they have learned to bypass by typing "agent" three times.

We build the whole thing: the retrieval layer that grounds it in your content, the guardrails that decide what it may and may not say, the integrations that let it actually do something rather than just talk, the handover into your existing inbox or helpdesk, and the monitoring that shows you what people asked and where it fell short. You own the code, the prompts and the data.

What you actually get

Built to be trusted

The difference between a demo and something you would put in front of paying customers is mostly in this list.

01

Grounded in your real content

It answers from your documents, product data and policies, not from whatever the model absorbed off the internet. Answers can cite the source, so your team can check them and customers can click through.

02

Knows when to stop

Confidence thresholds and refusal rules mean it says "I'm not certain, let me get someone" instead of inventing a plausible answer. The uncomfortable cases are exactly the ones that damage trust, so they go to a human by design.

03

Does things, not just says things

Check an order, book a slot, raise a ticket, issue a return, update an address, connected to your real systems through a controlled set of actions, each one permissioned and logged.

04

Clean handover to your team

When it escalates, a person receives the whole conversation, what the customer already tried, and a suggested reply, landing in the inbox or helpdesk your team already lives in, not a separate dashboard nobody opens.

05

Your voice, and your limits

Tone tuned to your brand, plus explicit boundaries: topics it will not discuss, promises it will never make, claims it is not allowed to invent. Written down, testable, and reviewed with you.

06

Visible and improvable

Dashboards showing what people asked, what it answered, what it escalated and what it got wrong, so the gaps in your own documentation become obvious and the assistant gets better every month.

Where it earns its keep

Same pattern, different desks

The pattern is the same everywhere, a queue of repetitive questions in front of a small team. What changes is the systems it has to reach into.

Retail & e-commerce

01 · Retail & e-commerce

The 60% of tickets that are all the same question

The problem
Where is my order, does this fit, can I return it, do you ship here. Volume spikes exactly when your team is smallest (evenings, weekends, sale periods) and slow replies turn into abandoned carts and chargebacks.
What we build
An assistant wired into your store and shipping provider so it can look up a real order, quote your real returns policy, and read the size guide for the specific product being asked about. Sits on the website, WhatsApp and Instagram at once.
What changes
The repetitive majority is handled the moment it is asked, and your team spends its day on the complaints and edge cases that actually need judgement.
Clinics & professional practices

02 · Clinics & professional practices

A front desk that never goes to lunch

The problem
Appointment requests, opening hours, what to bring, how much it costs, cancellation rules. The phone rings while your receptionist is with someone in person, and half the callers do not leave a message.
What we build
An assistant that handles booking, reminders and routine questions against your real calendar and price list, with strict rules about what it must not do: no advice, no diagnosis, no discussion of anyone's personal information without verified identity.
What changes
Fewer missed enquiries and no-shows, a front desk that can concentrate on the person in front of them, and an audit trail for every interaction.
Internal teams & operations

03 · Internal teams & operations

The colleague who has read every document

The problem
Staff interrupt each other all day for things that are written down somewhere: the expenses policy, which form to use, how to reset a client's access, what the process is for a refund over a certain amount.
What we build
An assistant on Slack or Teams with access to your internal handbook, wikis and process documents, respecting existing permissions so people only get answers they are entitled to see.
What changes
New starters get productive faster, your senior people stop being a lookup service, and the questions nobody can answer reveal exactly which documentation needs writing.

The technology

The tools behind it, named

We are not tied to one vendor. The right model for a given job depends on accuracy, cost, latency and where your data is legally allowed to live, so we pick per project, and we can move you later without a rebuild.

6 layers · 29 technologies

01

The models

The reasoning engine. Commercial models for the hardest conversations, smaller or self-hosted ones where cost, privacy or offline operation matter more.

  • OpenAI
  • Anthropic Claude
  • Google Gemini
  • Meta Llama
  • Mistral
  • Ollama

02

Knowledge & retrieval

What makes it answer from your material instead of guessing. Your content is indexed, searched at question time, and fed to the model as evidence.

  • LangChain
  • LlamaIndex
  • Qdrant
  • PostgreSQL + pgvector
  • Redis

03

Where it meets your customers

The assistant should live where people already are, not behind a login on a page they have to find.

  • WhatsApp
  • Slack
  • Telegram
  • Discord
  • Intercom
  • Web & in-app widget

04

Voice, when typing is the wrong interface

For phone lines and hands-busy situations: speech in, natural speech out, with the same grounding and guardrails as the text version.

  • ElevenLabs
  • Deepgram
  • Twilio

05

Connecting your existing tools

So the assistant can act: updating a CRM, creating a ticket, triggering a workflow in the systems you already run.

  • Zapier
  • n8n
  • Make

06

Where it runs

Deployed close to your users for fast replies, or inside your own infrastructure where the data is not allowed to leave.

  • Cloudflare
  • Vercel
  • Docker
  • Python
  • TypeScript
  • Node.js

Product names and logos are the property of their respective owners and are shown to describe the technologies we work with. Their use does not imply any partnership, sponsorship or endorsement.

How we deliver it

Live behind a human first

Six to ten weeks from first workshop to something answering real customers, depending on how many systems it needs to reach.

01

We read your last thousand conversations

Before writing anything we go through your real support history: emails, tickets, chat logs, the questions your team is sick of answering. That tells us what the assistant must handle on day one and what is rare enough to escalate.

02

We connect your knowledge

Documents, product data, policies and help articles are indexed so they can be searched at question time. Messy sources get cleaned up; contradictions between two documents get surfaced to you, because the assistant cannot resolve them and neither can your customers.

03

We write the rules

What it may say, what it must never claim, when it must escalate, what it is allowed to do in your systems, and how it verifies who it is talking to before revealing anything personal. Agreed with you in writing, then encoded as tests.

04

We test it against reality

The assistant is run against a suite of real historical questions with known correct answers, plus deliberate attempts to make it misbehave: prompt injection, off-topic bait, requests for information it should refuse. It ships when it passes, not when the demo looks good.

05

Soft launch behind a human

It starts by drafting replies your team approves before sending. You watch its accuracy on live traffic with no risk, and we tune it until you are comfortable letting it answer directly.

06

Then it keeps improving

Monthly review of what it got wrong, what it escalated unnecessarily, and which questions revealed gaps in your documentation. The assistant gets better, and so do your own help pages.

Before you commit

The questions worth asking

Will it make things up?

That is the risk everyone has heard about, and it is a real one. We reduce it by never asking the model to answer from memory. It only answers from documents retrieved at question time, and it is instructed to refuse when the retrieved material does not cover the question. We then test that behaviour explicitly with questions we know your content cannot answer. No honest supplier will promise zero errors; what we will do is make the failure mode "I don't know, let me get someone" rather than a confident invention.

What happens when it cannot answer?

It escalates. Depending on your setup that means opening a ticket, notifying a channel, or handing the live chat to whoever is on duty, with the transcript and the customer's details attached so nobody has to ask them to repeat themselves.

Where does our data go?

That is a decision we make with you before building, not after. Options run from commercial APIs with zero-retention agreements, through models hosted in a specific region for residency requirements, to models running entirely inside your own infrastructure so nothing leaves. The trade-off is cost and capability, and we will show you it honestly.

Can it work in more than one language?

Yes, and it is one of the strongest arguments for doing this at all. The same assistant can answer in the language the customer wrote in, from source documents written only in English, which is considerably cheaper than translating your entire help centre or hiring multilingual support staff.

What does it cost to run?

Ongoing cost is mostly per-conversation model usage plus hosting, and it varies enormously with how much context each answer needs and which model you are on. We model this with your real volumes during scoping so you get a monthly figure before committing, and we design for it: caching, smaller models for easy questions, larger ones only where they earn their keep.

What if we want to change model later?

We build behind an abstraction so the model is a swappable part, not a foundation. When something cheaper or better appears, and it will, you change a configuration rather than commissioning a rebuild.

Tell us what your customers keep asking

Send us the ten questions your team answers most often. We will tell you honestly which ones an assistant should handle, which ones it should not, and roughly what it would take.

Start the conversation