AI Chatbot Developer in Bangladesh: What to Bring to the Brief
Most chatbot projects fail at the brief, not the build. The four things to prepare before hiring, and the hour of testing that decides the outcome.
Most failed chatbot projects did not fail at the coding stage. They failed at the brief. The bot was built, it was clever, it was put on the website, and then it answered questions nobody asked while failing the ones everybody did — because no one had decided in advance what it was for or where its answers were supposed to come from.
So this guide is mostly about what you prepare before hiring, rather than how to judge a developer’s code. I build these from Bangladesh (GMT+6), and the clients whose chatbots work are, without exception, the ones who arrived with the four things below.
The four things to prepare before you hire anyone
- Your real question log. Not what you imagine customers ask — the last two hundred actual messages from your inbox, chat widget or phone notes. Sorted by frequency, this is the specification. It is also frequently a surprise: the most common question is usually something procedural like delivery timing or opening hours, not the product question you expected.
- A source of truth for the answers. One place — pages, a document, a help centre — that is correct and maintained. A chatbot is a reading interface over your content. If your content is wrong, out of date or scattered across three systems, the bot repeats that confidently and at scale, which is worse than silence.
- Escalation rules. Who receives a handoff, during which hours, and what happens outside them. A bot that cannot pass a conversation to a person is a wall with a friendly voice. Decide the destination before the build, because it changes the architecture.
- The boundary list. What it must never answer, written down. Medical or legal advice, custom pricing, anything about a specific person’s account, promises about delivery dates. This list is the difference between a useful assistant and a liability — what a chatbot can and cannot answer goes through how to draw the line.
A developer worth hiring will ask for all four. If nobody asks, you are being sold a widget rather than a system.
Whose API keys is it running on?
The answer should be yours. Your OpenAI or Anthropic account, your billing, the developer holding access rather than ownership.
Three reasons, in order of how much they will matter to you. You see the real usage cost instead of a marked-up monthly figure. You can change developer without changing anything technical. And you can switch models when the economics move, which they do — the tradeoffs between the main options are in GPT vs Claude for business chatbots, and the short version is that the model matters less than the content you point it at.
If a quote bundles “AI costs” into a monthly fee without showing the underlying usage, ask what happens when you have a busy month. It is a fair question and the answer is informative either way.
The running cost nobody quotes
A chatbot has a build price and a monthly reality. The monthly reality is smaller than most people fear: at around 500 conversations a month, the model usage itself typically lands somewhere between a couple of dollars and roughly twenty, depending on the model and how much context each answer carries. The worked arithmetic is in what an AI chatbot actually costs.
The cost that does bite is maintenance of the content: prices change, policies change, and a bot answering from last quarter’s version is a slow-motion complaint. Budget an hour a month for someone to look at what it got wrong and fix the source, not the bot.
And before commissioning anything custom, it is worth being honest about whether you need it. A ready-made platform is the right answer for a lot of businesses, and the comparison — including where the platforms genuinely win — is in custom chatbot vs Intercom vs Tidio.
How to test it before you sign it off
Acceptance testing a chatbot is not a demo. It is an hour of deliberate abuse, and it is the single most valuable hour in the project. Run it yourself rather than delegating it.
- Twenty real questions, taken verbatim from the log in step one, typos included. Score each answer correct, wrong, or evasive. Wrong is much worse than evasive.
- Five questions it should refuse, from the boundary list. It must decline and hand off, not improvise a plausible answer.
- Three angry messages. Frustration should shorten the path to a human, not trigger a cheerful FAQ.
- One invented product or policy. Ask about something that does not exist. A good bot says it does not know. A badly built one agrees with you, which is exactly how a chatbot invents a refund policy.
- The handoff, end to end. Trigger it and confirm a human actually receives it, with the conversation attached. Then trigger it outside business hours and confirm the customer is told what to expect.
The metric afterwards is not conversations handled. It is tickets that did not arrive — measured against the same question log you started with. That is the argument made in how to reduce support tickets with AI, and it is the only number that tells you whether the thing paid for itself.
Language, and why it belongs in the brief
If you are hiring in Bangladesh because your customers are here, say so at the start. A bot that has to handle Bangla, English and the mixture of the two that people actually type is a different build and a different test plan — not harder, but not something to discover at review. If your customers are elsewhere and write in English, this is a non-issue; I mention it only because it is the requirement most often left out of the brief.
Working across GMT+6
A chatbot is not a thing you commission and collect. The first fortnight after launch is a review loop — real transcripts, weekly, with the wrong answers fixed at the source. That loop matters more than the build hours, so agree it explicitly: who reads the transcripts, how often, and who fixes what they find.
Bangladesh being five to six hours ahead of the UK and ten ahead of New York works in favour of that loop: transcripts from your day are reviewed during mine, so the fixes are usually in place before you look again. The full timezone arithmetic is in the guide to hiring an automation consultant in Bangladesh.
What it costs, and how I build them
A custom chatbot starts at $900 for a focused build on your own content, and $2,800 for one wired into your systems with human handoff, both on the pricing page with 30 days of support after launch. It runs on your API keys, the content stays editable by you, and the escalation goes wherever you actually read messages.
Bring your question log to a free intro call and we can go through it. If the top twenty questions are all answerable by a better page on your website, I will tell you that instead — it is cheaper, and it works on the people who never open the chat widget.
Key takeaways
- Bring four things: the real question log, one maintained source of truth, escalation rules, and the list of what it must never answer.
- The keys and the billing stay in your account. That is what makes the developer replaceable and the cost visible.
- Model usage is usually the small cost. Keeping the content current is the real one — budget an hour a month.
- Test with twenty real questions, five it must refuse, three angry ones and one invented product. Then test the handoff, including out of hours.
- Judge it on tickets that never arrived, not conversations handled.
