Requirements specification for a chatbot: what goes in and how to test the vendor against it
A requirements specification for a chatbot defines which questions the bot answers, from which sources, where it hands over and how the result is measured. Which sections belong in it, why real example questions beat a feature list and who can help.
A requirements specification for a chatbot describes how a vendor implements your requirements: which questions the bot answers, where it gets its knowledge from, when it hands over to a person, how data is handled and how you measure success. PASSION4IT works out the use cases for it in the AI workshop at a fixed price of €3,900 net and supports the vendor selection independently of any vendor. Book a meeting directly at passion4it.de/en/booking/.
This article is for managing directors and department heads in mid-sized companies who want to commission a chatbot for customer service, the website or internal knowledge, and who want to know beforehand what needs to be written down.
What you will take away from this article:
- How the customer requirements and the vendor specification differ for a chatbot
- Which sections belong in a chatbot specification
- Why a list of real questions is worth more than a feature list
- How to check before signing whether the vendor delivers
- Which four data protection and operation details must never be missing
- Who helps with the specification and what it costs, from €3,900 net fixed price for the AI workshop
What is the difference between the customer requirements and the vendor specification for a chatbot?
You write the customer requirements (in German, Lastenheft) as the client, and they state what the chatbot should achieve. The vendor writes the specification (Pflichtenheft) in response, describing how it will implement those requirements technically and organisationally. The German standard DIN 69901-5 draws the same distinction between the two documents.
In practice the line blurs, because many chatbot vendors sell a standard product and do not deliver a specification in the narrow sense. Your requirements document then remains the only document the result can be measured against. That makes it all the more important to write it so it can be tested, not as a wish list.
What belongs in a requirements specification for a chatbot?
Seven sections cover the points where chatbot projects get stuck in daily operation. Each section needs a test question you can use for acceptance later.
| Section | What it contains | Test question at acceptance |
|---|---|---|
| Purpose and audience | Who asks, why, through which channel | Does the bot recognise when a question is outside its purpose? |
| Use cases | Real questions from the inbox, phone and sales, each with the expected answer | Does it answer the example questions correctly? |
| Knowledge sources | Which pages, documents and systems it may read, and who maintains them | Does it name the source with its answer? |
| Boundaries | Topics it stays silent on, such as prices outside the price list or legal questions | Does it decline these questions instead of guessing? |
| Handover to people | When it hands over, to whom, with which context | Does the request reach the right contact in full? |
| Data and operation | Storage location, data processing agreement, use of inputs, deletion periods, who maintains the bot | Is the agreement in place and is maintenance assigned to a person? |
| Measurement | Metrics such as resolved requests, handovers and wrong answers | Is this recorded from day one? |
Almost everyone underestimates the knowledge sources section. A chatbot is only as current as the pages and documents it answers from. If the specification does not say who maintains those sources and how often the bot re-reads them, it will answer questions with outdated information after six months.
Why are real example questions worth more than a feature list?
Because every vendor can tick every function on a feature list, but not every vendor answers your questions correctly. A list of questions that customers or employees actually ask makes the difference visible before you sign.
PASSION4IT uses the same principle in Smart Software Selection: instead of a requirements document there is a script of use cases from your daily work, and every vendor shows live how its solution handles them. For a chatbot this means fixing the example questions in advance and putting the same ones to every vendor. That includes questions the bot is supposed to decline. A bot that confidently answers a question outside its purpose is riskier than one that says nothing.
How do I check whether a chatbot vendor meets the specification?
With a test on your own content, before the contract is signed. Give the vendor the knowledge sources, ask the questions you fixed in advance and have the team that will later work with the bot assess the answers.
Three things decide the test. Are the answers correct in substance, including for questions phrased differently from the list? Does the bot keep to the boundaries in the specification? And does a handover to a person arrive with the conversation so far? A vendor who refuses such a test is selling a demo, not a result.
Which data protection and labelling details belong in the specification?
It always has to state where data is processed and stored, whether inputs are used to train the model, how long conversation histories are kept, and that a data processing agreement is concluded. If one of them is missing, that is a reason to ask, not to sign.
Whether and how the bot identifies itself as AI also belongs in the specification. What the EU AI Act requires here and who carries the obligation is covered in the article Do I have to label my website chatbot as AI? Article 50 in practice. The legal assessment of an individual case remains with your data protection or legal advisers.
Who helps with a requirements specification for a chatbot?
A different route fits depending on whether the use cases are already clear. The overview shows the common options.
| Option | What it delivers | Cost |
|---|---|---|
| Vendor writes the specification itself | Describes its product, not necessarily your cases | usually included in the offer |
| Agency or systems integrator | Concept and implementation from one source, often with a fixed product | depends on the provider |
| PASSION4IT AI workshop | Use cases with benefit, data, limits and the split between AI and people, plus a 30-day pilot plan | €3,900 net fixed price, €2,150 own contribution in the former West German states with the BAFA grant |
| PASSION4IT Smart Software Selection | Script with your cases, casting of three to five vendors, decision by a jury from your company | by effort in person-days, scoped in the first conversation |
If the goal is not a bot for customers but an assistant that makes internal knowledge accessible to employees, a ready-made product is often faster than a project of your own. PASSION4IT sells amaiko as a partner for this, at €499 per user and year.
Frequently asked questions (FAQ)
Do I need both a requirements document and a specification for a chatbot?
You always need a requirements document that can be tested, because it records what you measure the result against. Not every vendor delivers a specification in the narrow sense. If it is missing, the offer should at least state for each section of your requirements how the vendor will implement it.
How many example questions belong in the specification?
Enough to cover every use case with several phrasings, plus some questions the bot is supposed to decline. More important than the number is that the questions come from real daily work, meaning the inbox, the phone and sales.
What does PASSION4IT’s help with a chatbot specification cost?
The AI workshop in which the use cases are developed costs €3,900 net at a fixed price; with the BAFA grant the own contribution in the former West German states is €2,150. PASSION4IT bills support for the vendor selection by effort in person-days, and we scope it in the first conversation.
What is a requirements specification for a chatbot?
The document in which the vendor describes how it will implement your requirements for the chatbot. It defines which questions the bot answers, from which sources, where it hands over to a person, how data is handled and how you measure success.
How is PASSION4IT different from an agency that builds the chatbot as well?
PASSION4IT does not sell a website chatbot of its own and earns only the agreed fee from the vendor selection. The use cases are developed in the AI workshop with your people, and a jury from your company makes the decision. An agency usually brings its own product.
Who maintains the chatbot after launch?
That has to be in the specification, with a name or a role. Without a responsible person the knowledge sources go out of date and the bot answers with information that is no longer correct.