Why we interview the business instead of handing it a script

The first version of our setup was a form. A good form — clear labels, sensible defaults, the lot. It asked a restaurateur to choose a "human escalation strategy" and pick their "capability set". They closed the tab.

The vocabulary was the problem

Onboarding exists to gain knowledge about a business. Somewhere along the way most software turns it into a series of decisions the owner is not equipped to make — about our architecture, using our words. Nobody who runs a garage should have to learn what an escalation policy is in order to have their phone answered.

So the setup now asks about the business and nothing else. When do you open. How many can you seat. What do people ring about. What would you rather handle yourself. One question at a time, out loud or typed, with the platform’s own vocabulary explicitly banned from the conversation.

The machinery works it out

Everything technical is derived rather than asked. Which capabilities to switch on comes from what the owner said the calls are for. Hours and services are extracted from prose and validated. The things that genuinely have no sensible default are the only things anyone is asked twice.

• A question may only block a launch if machinery actually reads the answer.
• Anything the platform merely pastes into a prompt is knowledge, not a gate.
• Where an answer is missing, the capability that wanted it steps aside rather than standing between the owner and a working phone line.

A restaurant went from twelve required questions to nine. More importantly, the nine are all about the restaurant.