An intake agent only works if it knows the business — buildings, services, tenant types, regions, assets. That's a long form, and it's the very first thing a new customer meets. A blank six-field screen on day one, before any value is shown, is where trials go to die.

So the first screen makes a promise before it asks for anything — “Your Facilities, on Autopilot. Finally.” — then asks for one thing: your website URL. “Finally” is the load-bearing word; it speaks to someone who has already tried to solve this and is tired. You watch it crawl — rotating status lines keep a genuinely slow read feeling attended-to — then land on “Here's What We Found”: company, segments, services, tenant types, assets, regions, all pre-filled, all editable. The whole contract sits in one subtitle: “Edit any field — your changes always win.”

Every field is a question, not a label: “What's your company name?”, “Who are your tenants?”, “What assets do you manage?”— because the screen is a conversation about your business, and it quietly sets up the product's whole premise: you configure this thing by describing your work in your own words. Nothing is client-side state either — every keystroke autosaves, so a resumed session lands exactly where you left it, and the failure case is a first-class view, not a toast: “We Couldn't Read Your Site”, retry or fill it in yourself.

Then: prove it works before asking anyone to trust it

Submitting is a build, not a spinner — “Configuring your AI agent”drops you into Ask AI rather than an empty dashboard, because the useful first move is asking the product something, not surveying a bare helpdesk. And the very first thing after that isn't a feature tour — it's an offer to hear the thing you just built. You verify your phone number, and your own agent calls you: six OTP cells, one button — “Verify & call me.”

That's the highest-conviction moment in the whole product and it costs thirty seconds — nothing on a welcome screen competes with an AI agent phoning you and handling a maintenance request in your own language. It's skippable (“Explore My Own”), because a demo you can't decline is a hostage situation. The first thing a customer does is correct an agent that already understands their business, not build one from nothing.

The Intake agent is the biggest configuration surface in the product, and what it configures isn't settings — it's behaviour. How it sounds, how it opens, what it's allowed to handle, where it draws the line, when it hangs up.

So the General tab is ordered the way a call unfolds — Identity, Greeting, Behaviour, Scope of Work, Scenarios, end condition, closing message — with Actions deliberately last, because everything above is who the agent is and that's what it can do. Read the section subtitles as a sequence and you've been taught the mental model of a voice agent without a line of documentation.

The hardest field gets the most help: Scope of Work has a template library for the common case and a Draft-With-AI path for the long tail. Voices are cards you preview by ear, not names in a dropdown. And publishing is explicit — one Save And Publish, disabled until something changed, because agent behaviour is live to callers and shouldn't drift on autosave.

Closing the feedback gap

The config sits on the left; a phone mockup sits on the right — and it isn't a mockup of a call. It captures your microphone, streams to the agent over a socket, plays the response back, and prints the transcript as it goes. A real conversation with the agent you just configured, in the browser, no phone involved. That collapses the loop from edit → save → find your phone → call → hope down to edit → save → talk.

Dispatch is the moment the product asks for real trust. Telling a dispatcher “we've assigned Marcus to this job” asks them to accept a judgment they can't inspect — and a dispatcher who can't audit a decision will override it every time, which means the automation buys nothing.

So the entire reasoning is on the surface, not in a tooltip. The card leads with its own state — “Atom recommends” when it's awaiting your click, “Auto-assigned” when it already acted — then discloses three things: a confidence score stated as a number (“96% match”, not “high”); the ranked runners-up with their scores, so the winner is legible and the override is one scored click; and “How Atom decided”, the six steps the engine actually walked, each rendered only if the backend produced real reasoning for it.

The technician profile is a scorecard, not a contact card — first-time-fix rate, SLA compliance, skills rated 1–5, certifications, territories — exactly the attributes the engine ranks on, so the explanation and its data live in the same vocabulary. The dispatcher's job shifts from making every assignment to auditing them.

Dispatch policies are genuinely complex — severity thresholds, certifications, after-hours behaviour, travel distance, workload, cost ceilings. The conventional answer is a visual IF/THEN builder, which is miserable and caps expressiveness at its own grammar. The opposite — a text box that returns a black box — is easy to write and impossible to trust. And this rule decides who gets sent to a gas leak.

So: write prose → get structure back → simulate before you trust it. You describe the policy in plain language; the AI returns not prose but four labelled blocks that mirror how the engine executes — when it applies, who's eligible (a hard filter), how they're ranked (weighted bars summing to 100%), and assignment. That split between a hard filter and a weighted score is the one thing worth teaching, and the layout teaches it without documentation.

Then a playground: pick a real ticket, run the policy, see the technicians it recommends with a Top matchbadge — validated against reality before the rule ever touches a live request. It's the piece of thinking from this project I'd most want to reuse.

Every request the agents raise — from a call, WhatsApp, email, or the web widget — lands in one Tickets queue: one list, one row, one detail pane, one set of filters, so there's a single count of open work the whole team can trust.

The AI summary is the ticket's headline, credited “Summarized by Atom,”with the raw conversation always one chip away — nobody triages from a five-minute transcript. The detail opens as an overlay that slides over the table rather than reflowing it, so you can open six tickets in a row without losing your place. Attachments stay read-only: they're the caller's evidence, not yours.

Contacts is the directory behind every conversation — everyone the desk has spoken to, searchable by name, email, or phone. A caller who rings twice is one record, not two strangers, with their details and activity kept together in one place.

Ask AI searches the whole product in plain language and answers with the work itself — ask about tickets, technicians, policies, or trends and it comes back as the real records, each one a deep-link into the right filtered view rather than a paragraph describing them. Every conversation is kept in the rail, so you can pick a thread back up instead of re-asking.