A requirements document for an AI chatbot states, from your side as the client, which tasks the bot takes on, what knowledge it works from, where its limits are and how you will accept the delivery. A list of features is not enough, because the same question can get two differently worded answers. That is why the document needs real example questions with the expected reaction and pass thresholds for acceptance. For a first website assistant, four to six pages are usually enough, provided every section can be tested.
In German-speaking markets this document is called a Lastenheft. Under DIN 69901-5 it holds the client's requirements, while the supplier's Pflichtenheft (functional specification) describes how they will be met. The legal notes reflect the situation on 14 October 2026 and are not legal advice. The filled-in example is a constructed case, not a client project, and the thresholds are our proposal rather than a standard.
The eight sections at a glance
| Section and content | How you check it |
|---|---|
| Goal: which process gets lighter, with today's baseline | A number measured before launch |
| Tasks and exclusions: allowed topics, cases that are out | Real questions per topic |
| Knowledge: documents, systems, owners, update cycle | Every source has a named owner |
| Handover: triggers, what is passed on, hours | A tested route to the inbox or CRM |
| Channel and language: website, WhatsApp, languages, tone | Answers approved in advance |
| Privacy and law: data flows, processing agreement, AI notice, accessibility | Evidence, not general promises |
| Operations: cost cap, changes, export | A named person |
| Acceptance: test questions, thresholds, repetition | A signed test record |
Why a chatbot requirements document looks different
An AI chatbot is judged by its behaviour, not its features. “The bot answers questions about opening hours” is hard to accept or reject. It becomes testable once you write: “For these 15 questions the bot gives the hours from the contact page and, on public holidays, refers to the phone number.” Every requirement you can rewrite like this turns into a test case later.
Keep the document solution-neutral. Whether Claude, GPT or a self-hosted model does the work belongs in the supplier's specification. Your job is to set the conditions every proposal must meet: where data is processed, a cost cap, response time, how errors are handled. Make the contract say which document prevails if the requirements and the specification disagree.
Tasks and exclusions: start with real enquiries
The task list comes from the enquiries you actually receive, not from a brainstorm. Take 50 to 100 enquiries from the past few weeks out of your inbox, contact form and call notes, remove personal data and sort them into groups. For each group, decide whether the bot answers, collects details and hands over, or stays out because only a person should deal with it.
The exclusion list matters as much as the task list. Typical entries are price commitments, appointment confirmations without calendar access, complaints and any question where a wrong answer costs money or affects someone's health. Our article on hallucinations in customer service explains why this boundary comes before any tuning.
Knowledge and data sources: every source needs an owner
List each source with its content, format, owner and update cycle. Note whether customers may see it: an internal costing sheet does not belong in the knowledge base of a public bot. Conflicting versions of the same price list are resolved before the project starts, not inside the bot.
Anything that changes daily comes from the system that owns it: free appointment slots, delivery status, current prices. A PDF copy of that data is out of date on day one. How an assistant splits documents into passages, and where that goes wrong, is covered in RAG explained.
Handover, channel and operations
Handing over to your team is a requirement in its own right, with triggers, content and a destination. Common triggers are an explicit request for a person, an excluded topic, two unsuccessful follow-up questions and a complaint. Specify what is passed on: a short summary, the contact details and the relevant part of the conversation. Describe what happens outside business hours as well.
Start with one channel and one language. Each extra channel brings its own rules and fees, and each extra language doubles part of the test set. For operations, four points belong in the document: a monthly cost cap with defined behaviour once it is reached, a person who spot-checks answers regularly, a procedure for changes, and export of content and configuration if you switch supplier. The matching questions to put to a proposal are in our AI assistant cost guide.
Privacy, AI notice and accessibility
Write the legal requirements as evidence the supplier has to provide. That means an overview of all data flows including the model provider and logs, a data processing agreement under Article 28 GDPR and a justified retention period for each purpose. The full list is in our GDPR checklist for website chatbots.
Also require an AI notice at the start of the conversation. Article 50(1) of the AI Act obliges the provider to design a system for direct interaction so that people are told they are dealing with AI, unless that is obvious. According to the European Commission, the transparency rules have applied since August 2026. Have the document record who the provider of the assistant is and who checks the finished integration.
Accessibility can be mandatory too. Germany's Accessibility Strengthening Act (BFSG) covers e-commerce services provided to consumers after 28 June 2025. Micro-enterprises providing services are exempt under section 3(3); under section 2 no. 17 these are businesses with fewer than ten employees and annual turnover or a balance sheet total of no more than EUR 2 million. If your website is in scope, the requirements should cover keyboard operation and screen reader use for the chat window as well.
Acceptance: agree test questions and thresholds up front
Acceptance is agreed before development starts; otherwise each side ends up testing something different. For a first assistant we suggest 30 to 50 test questions: roughly six in ten regular questions from the allowed topics, two in ten excluded cases, one with missing information and one provocation, such as asking for another customer's data or trying to override the bot's instructions. Each question has a defined expected reaction: an answer with a source, a follow-up question, a handover or a refusal.
| Check | Threshold (our proposal) |
|---|---|
| Factually correct answers to regular questions | at least 90% |
| Unfounded commitments on prices, dates or goodwill | none |
| Excluded cases handed over or declined correctly | all |
| Disclosure of other people's data or internal documents | none |
| Unnecessary handovers on regular questions | at most 10% |
Two people from your team rate the answers independently and discuss the cases where they disagree. The test is repeated after every change to the model, the instructions or the knowledge base. Which measures are worth tracking separately is shown in the section on errors and consequences in our customer service hallucinations article.
A filled-in example: a heating contractor's service enquiries
A heating and plumbing business with twelve employees receives around 300 enquiries a month through its website and by phone. Many concern maintenance, the emergency service and the paperwork for subsidy applications. A short version of its requirements document could look like this:
- Goal: fewer routine calls about maintenance, emergency service and subsidy paperwork, from a baseline of 120 such calls a month
- Tasks: take maintenance requests, give the emergency number, explain which documents a subsidy application needs
- Exclusions: no prices, no remote diagnosis of faults, no appointment confirmation, no statement on whether a subsidy will be approved
- Knowledge: 14 service pages, maintenance FAQ, document checklist; maintained monthly by the office manager
- Handover: summary and phone number to the office inbox for faults, complaints or callback requests
- Channel: website chat, German, formal address
- Privacy: data flows with all suppliers, processing agreement, retention period justified by the business, AI notice when the chat opens
- Accessibility: chat window usable by keyboard and screen reader; the business checks whether the BFSG applies
- Operations: model costs capped at EUR 50 a month, after that a pointer to the phone and contact form
- Acceptance: 40 test questions, thresholds as above, repeated after every change
The whole document fits on five pages including the test questions. The exclusions are longer than the tasks, which is a good sign for a first assistant.
From requirements to effort
Individual lines in the document decide which effort range a project falls into. The hours come from the planning assumptions in our cost guide and are not a price list.
| Line in the document | Effect on effort |
|---|---|
| Public, reviewed content only, one language, handover by email | Website information bot, roughly 15 to 50 hours |
| One integration, for example a calendar or ticket system | Assistant with an integration, roughly 50 to 150 hours |
| Several systems, roles and approvals | Custom process assistant, roughly 150 to 400 hours |
| A second language or channel | More test questions and upkeep in every range |
| Conflicting sources | Clean-up before the project, whatever the range |
The heating contractor sits in the first line. As soon as the bot is meant to book maintenance slots straight into the calendar, it moves to the second. That decision is worth making deliberately, before you ask for quotes.
Frequently asked questions
What is the difference between a requirements document and a functional specification?
You write the requirements document: it sets out tasks, limits and acceptance from your company's point of view. The supplier writes the functional specification: it defines the model, architecture, integrations and operations they will use to meet your requirements.
How long should an AI chatbot requirements document be?
For a first website assistant, four to six pages plus test questions are usually enough. Integrations, extra languages or user roles make it longer; more detailed prose does not need to.
Can I write the requirements document with AI?
A language model can suggest a structure and wording. Tasks, exclusions and test questions still have to come from your real enquiries, or the document will describe an average business instead of yours.
What should a tender for an AI chatbot include?
The requirements document, the evaluation criteria and part of the test questions as examples. Keep the rest back for acceptance, so that proposals are not tuned to questions the bidders already know.
Which legal requirements apply to a chatbot?
For most website assistants in the EU these are the GDPR, the AI notice under Article 50 of the AI Act and, depending on what you offer, the BFSG in Germany. Roles and deadlines are explained in our AI Act guide.
If you have a draft, even an incomplete one, we are happy to go through it with you and point out which lines cannot be tested yet. Bring ten anonymised real enquiries and your list of exclusions. How we build an AI chatbot for websites is described on our service page.