A helpful website assistant answers approved questions and makes the next action easier. It should not invent prices, promise a guaranteed result or claim a booking is confirmed when no booking system was checked. Bangladesh customers may write in Bangla, English or a mixture. Start with the questions your team repeatedly receives, then write approved answers and identify which questions require a person. The technology should follow that boundary.
A familiar situation: illustrative example
Imagine a shop owner receives the same opening-hours question several times a day. An assistant can answer that approved fact. A request for a special discount should go to a person; the bot should not negotiate money on its own.
Design the workflow before the interface
Prepare a knowledge sheet containing service scope, exclusions, contact paths, business hours and the date each answer was checked. Keep public marketing material separate from internal documents. When information conflicts, the assistant should acknowledge uncertainty and ask for clarification instead of confidently selecting a convenient answer.
Test the exceptions and boundaries
Test difficult conversations: spelling mistakes, repeated questions, requests for discounts, instructions to ignore its rules and attempts to obtain private records. Include Bangla phrases used by real customers. A test passes when the assistant gives a useful, bounded answer or hands off safely. Counting the number of generated replies does not measure quality.
Choose the smallest workable solution
An AI provider may charge for requests and process conversation text. Explain this before sending a visitor’s message to an external model. Keep API credentials on the server, cap public usage and provide a non-AI fallback. If a request fails, say that a guided answer is being used rather than pretending the model responded.
A practical workflow
- Identify the question and preferred language
- Select approved service knowledge
- Explain scope and ask one useful question
- Offer relevant service links
- Hand a concise brief to a person
Acceptance checks before handover
Test a normal transaction, invalid input, a repeated request and an account without permission using representative business data. Check the agreed export. Write down account ownership, hosting responsibility, backup arrangements and the support route. Use test data before importing real customer records.
What to measure
Answer accuracy; unsupported claims; handoff success; cost per useful conversation. Record a baseline before launch and review the pilot against it. Software cannot guarantee improvement if the operating process and ownership remain unclear.
What the proposal should include
Separate features, users, imports, integrations, training and support in the quote. Ask for a BDT proposal and confirm whether hosting, API usage and third-party subscriptions are included. Custom development is different from subscribing to an existing SaaS product. Agree delivery dates after discovery and technical checks; unresolved integrations make fixed promises unreliable.
Common questions
Do we need every feature in the first release?
No. Start with one complete, testable workflow. Add modules after real usage shows what is missing.
Can the business move its data later?
Agree export formats, file access and account ownership in the proposal, then open an actual export during acceptance.
Further reading and next step
Compare the service with your workflow: AskFlow · AI assistant · Software catalogue · Discuss the project.