Before the Form, Understand the Business

The next booking system needed to serve more than one business. Before we could make that useful, we needed a better way to find out what each business actually did.

That sounds like the easy part. Ask what they sell, ask when it is available, add a price and build a form.

Then someone mentions that two activities can share a day but not an instructor. The person paying may not be the person taking part. A cancellation can mean the customer changed their mind or the venue cannot open. Those are not small variations in wording. They change what the system must do.

Ask questions the partner can answer

We built a small onboarding site around ordinary business questions rather than the internal vocabulary of a booking engine.

What should customers be able to book? What do they receive? Who can take part? How many places are available? How late can someone book? What happens if either side cancels?

The partner should not have to understand our data model before explaining their operation. Equally, a friendly form must not quietly remove distinctions the implementation will need later.

The sequence moves from the organisation and its launch goal, through the offering and schedule, to customer rules and a final review. It allows a description where a premature technical choice would be more likely to mislead than help.

“Not sure — please advise us” is a useful answer to a payment question. It identifies a conversation we need to have. It is better than forcing somebody to choose a policy they do not understand.

Keep the first tool small

The initial tool saves drafts in the browser and lets the partner download structured answers. It does not automatically publish them, configure a tenant or deploy a booking system.

That boundary is intentional. At this stage, the useful result is a reviewable account of the business, not an apparently complete configuration produced from unexamined answers.

Browser-local storage also has a limit: it is not a shared account or a server backup. The draft belongs to that browser's storage, and downloading it is an explicit step. “Saved” should not imply capabilities the tool does not have.

A form does not settle every question

The review page shows what has been answered and what remains blank. The export gives us consistent fields to work with, but consistency is not the same thing as agreement.

A partner can describe an offering clearly while leaving an important exception unstated. We still have to read the answers, ask follow-up questions and establish which rules are firm.

There is no evidence yet in this story that a questionnaire can replace that work. The tool gives the conversation a better starting point.

The useful output is understanding

The first TMS build taught us a great deal through implementation. The next build gives us a chance to carry those lessons into the questions we ask before implementation starts.

The onboarding site is a modest piece of that work. It helps a partner describe the outcome they want without having to design the technology themselves.

Before we turn a business into configuration, we need to understand the business. A cleaner form is useful when it helps us do that—and less useful when it merely hides what we have not yet understood.