A chatbot requirements document is what a developer builds the bot from and what you accept it against. For a small-business bot, one page with twelve short answers is enough. Every line you leave blank, the developer will decide for you, and you usually find out what they decided from a customer.
What to ask the developer before signing is covered separately in Business automation companies in Uzbekistan: how to choose one.
A chatbot requirements document template
Fill it in over an evening. Where you have no answer, write “don’t know”: better the developer learns about the gap before the build than after.
Chatbot requirements. Company: … Date: … Who answers the developer’s questions: …
- Goal and metric. The bot exists to … Today: … (how and over what period it was measured). After two weeks of running, success means: …
- Channels. Standalone Telegram bot / my own account via Telegram Business / website widget / WhatsApp. Main channel: …
- Languages and tone. Russian / Uzbek in Latin script / Uzbek in Cyrillic / English. Voice messages: yes or no. Tone: formal or casual (in Russian and Uzbek: вы/siz or ты/sen). The bot introduces itself as: …
- What the bot does. Three to five jobs, most frequent first: answers questions about …, books …, takes orders for …
- Where answers come from. Price list: … Catalogue: … FAQ: … Who updates them and how often: …
- What the bot never does. No prices outside the price list, no discounts, no deadlines that are not in the documents, no discussion of: … Instead it says: …
- When it hands over to a person. Topics: … Who takes the conversation: … How many minutes a person has to reply, day and night: … What the bot tells the customer meanwhile: …
- Money. Does the bot sell: yes or no. What the customer sees before paying: … Where payment details come from: …
- Where leads go. Spreadsheet / CRM / managers’ chat. Fields: name, phone, …
- Data. Which personal data the bot asks for and why: … Where conversations are stored: … Which AI model writes the replies, and on whose API key: …
- Who owns what. The bot and its token, accounts, server, model keys, code — registered to … Access handed over by: …
- Acceptance. Appendix: 20 real customer questions with the correct answer to each. The bot is accepted if: …
12 questions: what to write and what skipping costs
1. Why the bot exists and how you will know it works
One sentence on the goal and one “before” number. For example: “Reply to evening enquiries before morning; today they wait 11 hours on average, measured over one week of chats.” That figure is illustrative — measure your own.
If you skip it: there is nothing to accept the bot against, and “does it work?” gets settled by gut feeling. Why a single metric is easy to game and what to pair it with is in “What gets measured gets managed”.
2. Where the bot answers
A standalone bot and a bot connected to your own account are different things. A standalone bot is a new contact that customers have to find through a link. A Telegram Business bot answers on behalf of your account, inside your existing chats, and it has its own rules. According to Telegram’s documentation, only one such bot can be connected to an account at a time. When connecting it you can choose which chats it sees — for example, leave chats with your contacts alone — and later pause it in any single chat. It can only send messages in private chats where the customer wrote within the last 24 hours: it cannot broadcast to your old customer base from your account, and it will not answer in groups. Since 7 May 2026 such a bot connects without Premium; the details are in our article on Telegram auto-replies.
WhatsApp has a similar window. For 24 hours after a customer’s message you can reply with ordinary messages; after that, only with templates. For a website widget, decide how you will reach the customer if they close the tab: the bot should ask for a phone number or Telegram handle in time.
If you skip it: the developer builds a standalone bot, and customers keep messaging you directly, right past it.
3. Language and tone
List languages by share of customers, and for Uzbek, the script. Customers write in both Latin and Cyrillic, sometimes mixed with Russian, and the bot should reply in the script the customer used. Voice messages get their own line: without transcription the bot cannot understand them. Tone goes here too, along with how the bot introduces itself. In its first message it says it is an AI assistant, and it does not deny it when asked directly. How to test a bot in Uzbek in 30 minutes is in our article on AI in the Uzbek language. How we handle languages in AI agents is on the AI agents for business page.
If you skip it: the bot answers in Russian to someone who wrote in Uzbek, or in Latin script to someone who wrote in Cyrillic — and you find out from real customers.
4. What the bot does
Three to five jobs, not “everything”. Open last month’s chats and write down what people ask most often. For each job, note how it ends: an answer, a booking, an order or a handover to a person.
If you skip it: the developer builds the bot around their idea of your business, and your most common question ends up three levels deep in a menu.
5. Where the answers come from
The bot answers only from documents you gave it: price list, catalogue, FAQ, delivery and return terms. If something is not there, the bot does not know it and says it will check. Write down where each document lives, who updates it and how the bot learns about updates. If the price list is long, decide whether to send it in parts or as a link: a single Telegram bot message holds at most 4,096 characters.
If you skip it: the model answers from general knowledge — confidently, and not about you. Or the spreadsheet price list gets updated and the bot quotes old prices for another month.
6. What the bot never says
The stop list matters more than the feature list. It usually covers prices outside the price list, discounts, deadlines not stated in the documents, guarantees, diagnoses and medical advice, legal and tax opinions. For each item, write what the bot says instead.
A tribunal and a court have already put a price on skipping this: Air Canada had to pay for its chatbot’s promise, and a German court barred a clinic (in German) from what its bot had been saying about its doctors. Both cases are covered in Your website chatbot speaks for you.
If you skip it: the bot promises something you will then have to honour or dispute.
7. When the bot calls a person
Topics where the bot stops: a complaint, a refund, an exception to the rules, a request for a human, and everything on the stop list. Who takes over and in which channel, how many minutes they have to reply during the day and at night, what the bot tells the customer while they wait. And the reverse rule: once a staff member joins the conversation, the bot goes quiet.
If you skip it: the customer is told “passing you to a manager”, and the manager never hears about it. Or the bot and a staff member reply at the same time and say different things. Why handover is designed from day one rather than bolted on at the end is in Ironies of Automation.
8. If the bot sells
If the conversation ends in payment, write down what the customer sees before paying: an order summary, price, delivery, return terms, seller details. The bot copies payment details word for word from settings instead of paraphrasing them. What Uzbekistan’s e-commerce law requires of an offer and how to fit it into a chat is in Telegram shops and ZRU-792.
If you skip it: the terms of the deal end up scattered across twenty messages, and the model may get a card number wrong.
9. Where leads go
You need one place where a lead is sure to be seen: a spreadsheet, a CRM or a managers’ chat. List the fields the bot must collect and what happens to the lead next. If you have no CRM yet, a Google Sheet is enough to start.
If you skip it: leads stay buried in the bot’s chats, and someone has to dig them out by hand.
10. What data, where, and through which model
Three lines. Which personal data the bot asks for and why: under Article 19 of Uzbekistan’s Law on Personal Data (in Russian), the purposes of processing must match those stated when the data was collected. Where conversations are stored. Which AI model writes the replies, and on whose API key. Since 27 March 2026, only biometric data, genetic data and data on users of telecom operators’ services must be stored inside Uzbekistan; the rest can be stored and processed abroad if one of three conditions is met. Details are in Customer chats in ChatGPT and Claude.
If you skip it: your customers’ conversations end up with a provider you did not know about, under terms you never read.
11. Who owns the bot, the code and the keys
A Telegram bot’s token is the authentication key the server uses to control the bot — whoever holds the token holds the bot. Write down that the token, accounts, server, model keys and code are registered to your company and handed over before the pilot ends, not after the final payment.
If you skip it: the developer leaves, and the bot, the conversations and the keys leave with them.
12. Acceptance on 20 real questions
Attach twenty questions from real chats — with typos, voice messages and two languages — and next to each, the answer you consider correct. Add three or four provocations from the stop list: “give me a discount”, “is the doctor really a surgeon?”. The bot is accepted if it answers a share of questions agreed in advance and never breaks the stop list. Run the same twenty after every change.
If you skip it: the bot gets accepted on a demo the developer wrote themselves.
Brief or requirements document?
A chatbot development brief answers “why and for whom”: goal, customers, channels, budget, deadline. A requirements document answers “what exactly, and how do we accept it”. In the template above, the first three items are closest to a brief and the other nine are the requirements. The template has no budget or deadline: if you send it as a brief, add them yourself. If a developer sends you their own questionnaire, the answers carry over with almost no edits.
When a formal GOST 34.602 specification makes sense
In Russian-speaking countries, the technical specification (tekhnicheskoe zadanie) even has its own formal standard: GOST 34.602-2020, the interstate standard for specifications of automated systems. It was adopted by the Interstate Council for Standardization under protocol No. 58 of 22 December 2020, and Uzbekistan, through its national standards body Uzstandart, voted for it. In Russia it has applied since 1 January 2022, replacing GOST 34.602-89 (text of the standard, in Russian).
The standard requires ten mandatory sections, and even a section with no requirements stays in the document with a note saying so. It includes, for example, the sources of funding and requirements for preparing the organisation for the system’s launch. For a large system or a government client that is justified: lawyers, auditors and the next contractor will read the document. If your contract or procurement rules explicitly require a GOST specification, write one.
For a salon’s or a shop’s bot, ten sections become paperwork someone pays for by the hour. One rule from the standard is worth keeping, though. Clause 3.4 says requirements should be singular, consistent, current, feasible, verifiable and unambiguous. Check every line of your template against the last two. “The bot is polite” cannot be verified. “The bot addresses customers formally and replies in no more than three sentences” can.
We could not establish whether GOST 34.602-2020 is in force as a national standard in Uzbekistan. Each country publishes that in its own index of national standards. The standards catalogue at standart.uz did not open for us, and we found no answer in open sources. Check its status with a lawyer before citing it in a contract.
Where we stand, honestly
We build chatbots for business: on Telegram, and on WhatsApp through the WhatsApp Business API as part of a project. We do not have a WhatsApp bot running yet. Many of the template items are part of our process: the script is agreed in writing before the build, the metric is fixed in writing before the start, and what goes to the model is written into the requirements. A bot for one process is our Pipeline package: from $1,200 plus $300 a month, two weeks.
The way in is a free review: six questions in the quiz, an answer within 48 hours, no call needed. What comes back is a map: what can be taken off your team’s plate, in what order and what it costs. The requirements document is written later, as part of the project.
We have no client case studies with numbers yet: the company has been operating since August 2026. We do have our own bot. Valli is an AI auto-responder for Telegram Business and website widgets, currently in pilot. Some items of this template are covered by its settings: prices and deadlines only from the owner’s profile and catalogue, “I’ll check with the owner” when the answer is not there, payment details copied word for word from settings, and two hours of silence in any chat where the owner has replied personally. That is how Valli worked when we checked its code in September 2026. It has no separate rule for refunds: those fall under the general “not in the profile — check with the owner”, so everything depends on what the owner wrote in the profile.
The template is not tied to us — send it to any developer. If items 1, 6 and 7 are hard to answer, describe the process in the quiz on the home page: within 48 hours we will send back which questions the bot can handle itself and which it must pass to a person.
