The AI Front Desk Engine

What the Front Desk Does for You

A customer texts at 9pm. You are home. Your team is home. Without help, that text waits until morning, and so does the job.

Our front desk answers it. It reads the text, knows who sent it, and replies the way your best advisor would. It asks what it needs to ask. It books when it can. When a person should take over, it says so and hands the thread to your team.

It is not a chat bot that reads a script. It is Claude, a language model, working inside rules we wrote from running a real shop. Those rules are the part that took the longest. They are also the part that keeps it from embarrassing you.

One Durable Object per Conversation

People do not text in full paragraphs. They send three short texts in ten seconds. If each one gets its own answer, the customer gets three replies that talk over each other.

So every conversation gets its own durable object on Cloudflare. That is a tiny program with its own storage that handles one thread and only one. Texts for that thread line up in order. Each new text resets a short timer. When the customer stops typing for a few seconds, the whole burst goes to Claude as one message.

export class Conversation {
  constructor(state, env) {
    this.state = state;
    this.env = env;
  }

  async fetch(request) {
    const msg = await request.json();
    const queue = (await this.state.storage.get("queue")) || [];
    queue.push(msg);
    await this.state.storage.put("queue", queue);
    // A new alarm replaces the old one, so each text restarts the wait.
    await this.state.storage.setAlarm(Date.now() + 8000);
    return new Response("queued");
  }

  async alarm() {
    const queue = (await this.state.storage.get("queue")) || [];
    await this.state.storage.delete("queue");
    if (queue.length) await this.reply(queue);
  }

  async reply(messages) {
    // Look up the caller, check for a human, then ask Claude.
  }
}

Because one object owns one thread, two replies can never race. That class of bug is gone by design.

The Rules That Run Before Claude Speaks

The first message does the most damage, because it goes out before anyone can see it. So a set of plain checks runs first.

• STOP means stop. STOP and the other standard opt out words end the thread at once. No reply, no follow up.
• Is a person already here? If someone on your team typed in the thread, the bot stands down.
• Who is this? The number is looked up before any words are chosen. A customer with a car in the shop hears about their car. A stranger gets the plain greeting.

const OPT_OUT = new Set(["STOP", "STOPALL", "UNSUBSCRIBE", "CANCEL", "END", "QUIT"]);

export function isOptOut(text) {
  return OPT_OUT.has(text.trim().toUpperCase());
}

The lookup is built to fail open. If the match is not exact, it falls back to the stranger reply. A slightly generic message is fine. Silence is not.

Hand-Off Without Walking Away

Handing a thread to a person cannot mean the customer is left alone. If nobody on the team replies, the thread goes quiet, and the lead goes cold.

So hand-off is a grace period. Your team gets a window to jump in. The moment a real person replies, the thread is theirs for good. If nobody does and the customer is still waiting, the front desk picks it back up. It still follows the limit on how many questions it may ask.

Never a Price Nobody Approved

A text thread that ends in a number is a promise. The bot never makes one on its own. It uses the same quote builder your staff use, drafts the estimate, and leaves it for an advisor to approve. The customer sees a total only after a person says yes. Showing it sooner is a small code change and a large business decision, so it stays the owner's call.

Knowing Who Sent Each Message

Once your team can type into the same thread, the bot has to tell its own texts from theirs. It does that by matching each outbound text against the words it recorded sending. No match means a person typed it.

This sounds simple and it is easy to get wrong. Text providers often add opt out wording to the first message. So the words that went out are not quite the words that were saved. We match on the start of the message in either direction. We also ignore very short texts, since a bot's "Got it" could match a person's reply by accident.

We also record both sides of the thread before the bot decides to stay quiet. If that order is flipped, a thread where your team did all the talking looks empty, and your reports say nobody answered.

What It Saves the Owner

You stop losing the after hours text. You stop paying someone to answer the same questions all day. Your team walks in to threads that are already sorted: booked, waiting on a quote, or needing a person. It is live today for Shop Desk shops, and it is the core of our answering service.

What We Learned the Hard Way

Alarm on what the customer got, not on whether the job ran. We once had a sender that ran on schedule and failed every time. A monitor that asked "did it run" stayed green the whole way. Ours asks one thing: is anyone waiting on an answer with nothing coming back?

Watch out for a false all clear. On a quiet night, a real outage can age its own waiting threads out of the window, and the list goes empty. So the all clear needs proof the bot spoke recently, not just an empty list.

Read the words, not just the logs. Generated replies drift longer and ask more questions than a real person. We read a day of them next to what your team typed, and tune the voice from there.

For the full build, see the AI front desk build. Next in the stack is search and indexing.