Write the outcome into your chatbot brief, not a feature list

The short answer

If your brief says “website widget, answers from our PDFs, human handoff, WhatsApp”, you will get a bot with a widget, PDF search, a handoff button and WhatsApp. Whether it answers the questions your customers actually ask, and whether anyone notices when it doesn’t, was never written down, so nobody built for it.

Write the outcome first: what should be true for a customer or for your team when the bot works, in terms you can check. “Every question about delivery times gets a correct answer within a minute, and anything about refunds reaches a person the same working day.” Then let the builder propose the features that get there. The outcome line becomes the test you accept against, which is how the chatbot job page brief is laid out: Goal first, Acceptance near the end, both measurable.

Why a feature list produces the wrong bot

A feature list answers “what should it have?” A freelancer can deliver every item on it honestly and still miss what you needed, because the list says nothing about:

• Coverage. Which questions, from which customers, on which channels.
• Correctness. What counts as a right answer, and how many wrong ones are acceptable.
• The quiet cases. Messages that arrive and get no answer at all. A feature list never mentions them, and they are the ones that cost you customers.

Features are also easy to argue about after the fact. “It has handoff” is true if a button exists. “A person receives the conversation, with the history, within an hour” is either true or not.

What an outcome line looks like

Take each feature you were going to write and ask: what should happen because of it?

Feature you might write	Outcome to write instead	How you check it
Answers from our FAQ and PDFs	Answers our 30 most common questions correctly, and says “I don’t know” to anything outside them	Run the 30 questions plus five it should not answer
Human handoff	A person receives the conversation, with history, within one working hour	Trigger a handoff; time it
WhatsApp and website	A customer on either channel gets the same answer to the same question	Ask the same five questions on both
Refund questions	Never promises a refund; every refund request reaches a person the same day	Ask three refund questions three ways
Analytics dashboard	Each week I see how many questions went unanswered or were handed over	Look at the first weekly count

The right-hand column is the one that turns into your acceptance test. How to test a chatbot before you accept it walks through running exactly this kind of sheet.

A small bot of mine that met its spec and missed its outcome

I run a small bot that replies to comments on my social posts and sends a download link by direct message. Its “features” were all there, and working. Its outcome, everyone who asks gets the link, failed three times in different ways:

• It looked in the wrong place. It checked only the 12 newest posts. Because I publish several a day, that covered about a day and a half, and two comments on an older post were never even attempted. (The webhook explainer tells that one in full.)
• Some comments were invisible to it. When I paid to promote a post, the platform created a separate copy of it for the ad, and the list my bot read did not include that copy. On one post, all five ordinary comments were answered and the four comments on the promoted copy got no reply for three days.
• My first check said everything was fine. I compared the bot’s list of comments with a comment count from the same source. They matched, because both had the same blind spot. The missing comments were only visible in the app itself.

A separate job of mine that turns a list into a one-page image had the same shape of problem. I capped it at eight items to keep the text readable. The cap worked, and on one post only 5 of 21 items made it onto the page while the voice-over said everything was on screen. The number of items shown was being recorded, and nothing read it.

In every case the feature was delivered. The outcome was never written down as something to count, so nothing counted it.

Turn outcomes into the brief

Put the outcomes in the fields a builder reads first. The chatbot job page brief has them already; this is how to fill three of them:

Goal. Customers get a correct answer to our 30 most common questions within a minute, on the website and WhatsApp. Anything else: “I’m not sure, let me connect you.” Handoff. A person receives the conversation, with history, within one working hour. Refund, complaint and legal questions always go to a person. Acceptance. Final payment when the bot passes my 30-question set with no more than [N] wrong or made-up answers, refuses the never-do list, and a handoff reaches a person with history. After launch, a weekly count of unanswered and handed-over conversations.

Then send the material the bot answers from; what to give a chatbot developer before they start lists it.

How sellers respond to an outcome brief

A good builder will push back on the numbers, and that is useful. “Thirty questions correctly” may become “twenty-five, and the other five go to a person”, which is a better bot than one that guesses. Some will ask for more of your real questions. That is also a good sign.

On the chatbot job page, Bensbahou mentions documentation, testing and human handoff in the gig, which are the pieces an outcome brief leans on. What buyers said in 252 chatbot developer reviews shows how these projects usually go.

Where it goes wrong anyway

• The questions change. New products bring new questions. Re-run the question set when your offer changes, and agree who updates the material.
• Only the good conversations get looked at. Transcripts of happy customers are pleasant to read. The weekly count of unanswered ones is the number that matters.
• The outcome is too vague. “Improve customer experience” cannot be tested. If you cannot say how you would check it, rewrite it until you can.

Wrap-up

A feature list tells a builder what to install. An outcome tells them what to achieve, and tells you what to test. Write each line as something that happens for a customer, with a number and a check, include the messages that get no answer, and use the same numbers for acceptance. Then “done” means the same thing to both of you.