What to give a chatbot developer before they start

The short answer

A chatbot does not know your business. It knows what you hand over, and where there is a gap, it will either guess or say nothing useful. So the hand-over pack decides most of the result before any code is written.

Send seven things before the build: the documents it answers from, about 30 real questions with the answers you expect, a never-do list, escalation rules written as triggers, any actions it must take, tone and languages, and accounts in your name. The brief on the chatbot job page has a field for each. This guide is about what to put in them.

Why the hand-over matters more than the tool

Most chatbot builders on the market can connect a model to your documents. What differs between a bot your customers trust and one they avoid is mostly outside the code: what it was given to read, what it was told never to do, and what it does when it does not know.

I do not run a customer chatbot. I do run AI jobs that work unattended from written instructions, including a nightly drafting job in my content pipeline, and an automation that answers people who comment on my posts by sending them a direct message. Three things from those records apply directly to a chatbot brief:

A gap in the instructions gets filled. In an early test, my drafting job produced a draft with one sentence describing something that had happened in my own automations, without saying where it came from. The event turned out to be real, but my first search missed the record, and nothing in the instructions required the writer to name a source. The same gap would have let a plausible invention through just as easily. For a chatbot, that is the invented refund policy or the made-up opening hours.

The fallback must be written, not assumed. My comment-to-message automation once failed on the same comment six times, every 20 minutes. The same login had worked on another comment 40 minutes earlier, so I concluded the recipient’s settings did not allow the message. The fix was a rule: after two failures, stop retrying, post a short public reply asking the person to send a message first, and continue in that conversation when they do. That is an escalation rule. Without it, the automation just kept knocking on a closed door.

A good system reports what it cannot do. In another test, the shell cut my drafting job’s instructions off at the first quotation mark, so the tool received only the first five words. It noticed and reported the problem instead of guessing what the rest might be. That is the behaviour you want from a chatbot too: “I don’t know, let me connect you” is a feature, and it only exists if you ask for it.

Seven things to send before the build

Items 2 and 4 are the ones buyers skip and later regret. The job page ties final payment to the 30-question test, a never-do check and a working handoff, which is the acceptance list.

Escalation rules you can copy

“Escalate when needed” leaves the decision to the bot. Write each rule as a row:

When	The bot does	Who receives it	Within	Customer is told
The customer asks for a person	Hands over with the full history	[name / shared inbox]	[working hours: 1 hour]	“I’ve passed this to [team]; they’ll reply here by [time].”
The answer is not in the documents	Says it does not know, offers a handoff	Same	Same	“I don’t have that information. Want me to connect you?”
A never-do topic comes up	Declines, offers a handoff	Same	Same	“I can’t help with that here, but [team] can.”
The same question fails twice	Stops, hands over	Same	Same	Same as above
An action fails (booking, lookup)	Does not retry silently, hands over	[who owns that system]	[time]	“That didn’t go through; [team] will confirm.”

The fourth row is the lesson from my comment automation: decide in advance how many attempts are enough, and what happens after.

What not to hand over

• Passwords to your own accounts. Create the AI provider, hosting and integration accounts yourself and give access you can remove. If the bot runs on the developer’s key, it stops when their account does, and you cannot see what each conversation costs.
• Your whole drive. Send the documents it should read, as copies. Everything you send is something it may quote.
• Out-of-date material. Old price lists and retired policies get answered from as confidently as current ones. Remove them before you send.

Check the pack before you send it

A useful test: give your 30 questions and your documents to someone who does not know your business, and ask them to answer from the documents only. Wherever they get stuck, the bot will guess. Fix the documents, not the prompt.

I added a similar step to my own drafting job after the invented sentence. A separate, read-only check now compares every number and first-person claim in a draft against the files before anything is scheduled (what that looks like in practice). Its instructions also tell the writer to put a topic on hold rather than write it when the record cannot be found. For a chatbot, the equivalent is your 30-question test run by you, not by the builder, with a pass mark agreed before the demo.

Where it goes wrong anyway

• Nobody owns the documents after launch. The bot is right on day one and wrong by month three. Name the owner, and agree who updates the knowledge and at what rate; see putting maintenance in the contract.
• The test set is written after the demo. Then it tests what the bot already does. Write it first.
• The handoff is tested once, by the builder. Test it yourself, at night and on a weekend, and check that a person actually receives the conversation with its history.

On larger projects, tie each milestone payment to its part of the tests. The reviews behind what 252 Fiverr reviews say about hiring a chatbot developer point the same way: the questions and the milestones are settled before the first order.

Wrap-up

A chatbot is a system for answering from your material under your rules. Hand over the material, the real questions, the never-do list and escalation rules written as triggers, on accounts you own. Then the developer can quote the real job, and you can test the result against something you wrote before you saw it.