Brief Your AI Assistant in Plain Language, Not Settings

There is a moment in most implementations where an operator stalls. They have been shown a configuration screen, or a list of prompts, or a settings page, and they are trying to work out what to put in it. Progress slows, and it stays slow until someone says a version of this:

Just write me, in free text, what you want to happen.

That instruction unblocks more projects than any feature.

Why plain language works better

The property knows how its operation runs. The implementation team knows how to express that in the system. Problems start when either side tries to do the other's job.

When an operator tries to think in configuration terms, two things go wrong. They constrain themselves to what they imagine is possible, which is usually narrower than reality. And they describe mechanisms rather than outcomes, which strips out exactly the context that makes the requirement clear.

A description in ordinary sentences avoids both. It carries intent, and intent is what can be built against.

What a good brief looks like

Here is a complete, useful brief. It took a few minutes to write and contains everything needed:

A guest asks about booking a birthday party on a Saturday. The assistant should check the party room calendar for that date. If there is a free slot it offers the available times. If the day is full it says so directly and offers the two nearest dates that are free. If the group is larger than twenty it should not quote availability at all - it takes their details and tells them someone will call back.

Notice what that paragraph does. It names the trigger, the system to check, the successful response, the unsuccessful response, and an exception with different handling entirely. It reads like an instruction to a new member of staff, which is exactly the right register.

Now compare it with how the same requirement usually arrives: we need availability checking for the party room. That sentence is not wrong. It just leaves every decision that matters unmade.

The branch everyone forgets

Operators describe the happy path fluently. A guest asks about X, the assistant tells them Y.

Guests spend most of their time on the other branch.

What happens when the answer is no? When the request is outside what you offer? When the assistant is not confident? When the date is in the past, or the group is too large, or the thing they are asking about was discontinued last season?

Those responses determine whether guests trust the channel. An assistant that says that Saturday is fully booked, but I have availability on the Sunday or the following Saturday builds confidence. One that goes vague, or improvises, destroys it in a single exchange.

So when writing a brief, force yourself through the negative cases explicitly. For every behaviour you describe, add a sentence beginning if not, then.

Much of it may already exist

Here is something worth knowing before you start writing: a good part of what you describe is probably already built.

Logic like availability checking and escalation routing tends to be implemented generically and then pointed at specific cases. An availability flow written for one type of booking usually handles another with configuration rather than development.

You cannot tell from the outside which is which, and you do not need to. Write the description, hand it over, and let the implementation team tell you which parts are configuration, which need building, and which already work exactly as you described. That conversation is fast and concrete. Trying to guess in advance is slow and usually wrong.

Then ask for a simulation

A brief is a specification, and specifications need testing before anyone relies on them.

Once the description is implemented, ask for it to be run against real cases before go-live. Real dates, the real connected calendar, the real edge cases - a fully booked day, a closed day, a group over the threshold, a request phrased awkwardly.

Two things come out of that. You find out whether the behaviour matches what you meant, which is not always what you wrote. And you find the cases you did not think of, which is most of the value.

Write it like you would brief a person

The most reliable heuristic: describe it the way you would explain it to a competent new employee on their first shift.

You would not hand them a settings page. You would say when someone asks about this, check that, and if it is full tell them so and offer the nearest alternative. Anything over twenty people, do not quote anything, take a number and pass it to me.

That is a complete, unambiguous, testable brief. It is also exactly what an implementation team needs, and it takes less time to produce than a single round of trying to reverse-engineer the same thing from a configuration screen.