A chatbot for handling inquiries is one of the most common purchases of recent years: government agencies and large companies want to lighten the load on their call center, let a bot in Telegram and on the website handle routine questions, and leave only complex cases to human agents. On paper the task looks simple: the bot answers frequent questions and logs inquiries. In practice it's a system with a knowledge base, logic for handing conversations over to a human, storage of chat history, and quality requirements for answers -- and these are exactly the parts a typical technical requirements document describes worst.
The client is usually an agency or a company with an existing call center that wants to reduce the load on its agents, not build something fundamentally new. That's where the trap lies: the document gets written on the assumption that 'the bot already knows everything,' forgetting that someone has to feed the bot that knowledge and keep it updated.
The quality of the finished bot isn't determined by how polished it looks in a demo, but by how precisely the requirements describe the source of its answers, the escalation scenario to a human agent, and the criteria by which acceptance will say 'the bot works.' If that's missing from the document, a dispute at acceptance is almost inevitable -- and it will have to be resolved after payment has already been made.
We do not name buyers or tenders: we look at a typical spec, not at anyone's procurement.