System 01 · Intake & booking

The call you never knew you lost.

A missed call leaves no record. It is the only loss in an appointment business that is completely invisible in your own reporting, because the appointment was never created. This system answers, qualifies and books, inside the software you already run.

Why missed contact is the hardest loss to see

Every other leak leaves a trace somewhere. This one does not, by construction. A booking that was never made creates no row in any system, so the number never reaches a dashboard or a management meeting.

+ The four ways it happens

It never enters your data

A booking that was not made creates no row in any system. You can report on no-shows, cancellations and utilization because those exist as records. The call that rang out at 19:40 exists nowhere, so it is absent from every dashboard and every management meeting. Businesses do not underestimate this number, they have never seen it.

It arrives exactly when you cannot answer

Inbound demand is not evenly spread. It clusters after work, at weekends, at lunchtime and in the first hour of Monday, which is precisely when your staff are with clients or on the other line. The busier you are, the more you lose, which is why the problem grows with success.

The caller does not wait

A person looking for an appointment is comparing options. They do not leave a message and wait for a callback, they call the next name on the list. By the time anyone at your end knows there was interest, it has been converted by someone else.

A callback is not a recovery

Even where a message is left, the callback happens hours later into a different mood and a different moment. Conversion from a returned call is a fraction of conversion from a call answered while the person is still deciding.

What the system actually does

Four things in sequence, on every contact, in every channel you connect.

1

Answers and identifies

Picks up calls, messages and form submissions without a queue. Establishes whether the contact is a new or returning client and pulls the existing record where one exists, so a returning client is not asked to re-explain their own history.

2

Understands and qualifies

Captures the reason for the contact in the language the caller used, applies your urgency rules rather than inventing them, and asks only the questions that change what happens next. Rules are written down before launch and belong to you.

3

Books or hands over cleanly

Where the scheduling system permits a write, it checks real availability and creates the appointment, then confirms in the channel the client prefers. Where it does not, it prepares the record and escalates to a named person with the full context attached, which is a different thing from a callback request.

4

Leaves a record either way

Every contact produces a structured entry: who, when, what they wanted, what happened, what is outstanding. This is the part that changes management, because the calls you used to lose become countable for the first time.

One integration underneath. The same connection carries retention, conversation analysis and planning if you add them later.

The parts that are usually done badly

Most disappointment with automated intake comes from four specific failures, and each is a design decision rather than a limitation of the technology.

+ The four failures, and what we do instead

Escalation without context

Transferring a caller into a queue where they start over is worse than an honest voicemail. Handover carries identity, reason and progress, or it is not a handover.

Pretending to be a person

A system that dodges the question of what it is loses the call the moment the caller suspects. Disclosure is configured deliberately and, increasingly, is a legal requirement rather than a style choice.

Answering questions it should not

Clinical, pricing and eligibility questions have boundaries. What the system may answer is documented and bounded; everything else routes to a person rather than being improvised.

Treating every call as a booking

A large share of inbound volume is directions, opening hours, spam and wrong numbers. Handling those cleanly and quietly is most of the relief your staff actually feel.

How it connects, and how it is measured

The interface your scheduling system exposes decides the depth of the work. The result is compared against your own numbers.

Open booking API

Live availability read, appointment written back, confirmation sent. First production workflow usually two to six weeks.

Partial API

Everything permitted is automated and the last step is handed to a person with the caller, the reason and the requested time already captured.

Closed system

Answering, qualification and record preparation still work; booking stays manual until an interface exists. We say so before quoting when the gain does not justify the build.

Baseline before launch

Answer rate, booking rate from inbound contacts, out-of-hours volume and escalation rate recorded first, with a holdout share routed as before where volume allows.

What we need from you

Access to the scheduling systemThe live system or its documentation, so integration depth is established from reality.
How contact is handled todayWho answers, when, what happens out of hours, and what currently goes to voicemail.
Urgency and escalation rulesWhat is urgent, what routes straight to a person, and what the system must never answer. Written down before launch.
Your disclosure and recording positionWhether callers are told they are speaking to a system, and how consent and recordings are handled in your jurisdiction.
An agreed metricThe single number this project is judged by, decided before launch.

Questions we get asked

Will callers know they are talking to a system?That is a decision you make and it is written into the configuration before launch, not left to the model. In several markets disclosure is becoming a legal requirement rather than a courtesy, and the rules differ by jurisdiction and by sector. We build to the rule that applies to you and we do not claim compliance we have not implemented.
What happens when the caller asks something the system cannot answer?It escalates, and how it escalates is the part that matters. A transfer that drops someone into a queue with no context is worse than voicemail. The system hands over the caller identity, the reason for the call, what has already been established and what remains open, so the person picking up starts informed rather than starting again.
Can it actually create the booking, or only take a message?It depends on one thing: whether your scheduling system allows an appointment to be written through an interface. With an open booking API it reads live availability and writes the appointment back directly. With a partial API it does everything permitted and hands the final step to a named person with everything captured. With a closed system it answers, qualifies and prepares the record, and booking stays manual. Which case you are in is established during scoping by examining the live system.
How does it handle a caller who speaks a different language?Language is detected from the caller and the conversation continues in it, including in a mixed client base where one household switches languages mid-call. Which languages are covered is confirmed during scoping rather than promised in advance, because coverage quality is uneven across languages and a bad accent is worse than a polite handover.
What about spam, wrong numbers and people who just want the address?A large share of inbound volume is not a booking opportunity at all, and treating it as one is how these systems become annoying. Simple informational calls are answered and closed. Spam is identified and dropped. What reaches your staff is filtered, which is often the change they notice first.
Does every call get recorded, and where does the recording live?Recording is configured to your rules and your jurisdiction, including whether consent is captured at the start of the call and how it is stored. Where recordings and transcripts live is your decision: your own infrastructure, in the region you specify.
How do we know it is working?Answer rate, booking rate from inbound contacts, calls recovered outside staffed hours, escalation rate and average handling time, all measured against a baseline recorded before launch. Where volume allows, a holdout share of contacts is routed as before so the comparison is against your own traffic in the same period rather than against last year.
How long does it take to launch?A first production workflow typically launches in two to six weeks. The variable is almost never the conversation itself. It is what the scheduling system permits and how quickly the rules for escalation and urgency can be agreed and written down.
Let's scope it

Start by counting what you are currently losing.

Answer five questions and the brief writes itself, or write to us directly. Either way you get an initial solution brief. A proposed architecture and a fixed quote follow a scoping call, once we have seen your systems.

Build a brief → Contact form