How to choose a chatbot and prepare a project brief

How do you decide what kind of chatbot you need?

Start with the action the customer needs to complete. Finding your address, choosing a service and confirming a calendar booking require different logic. A prepared reply may answer the first question. A short guided flow can handle the second. Questions written in the customer's own words may benefit from AI using approved company material.

List a few typical enquiries without names or contact details. Write the desired outcome beside each: an answer received, details collected or a staff member involved. Mark any information needed from another system. This gives you a practical scope to discuss and a consistent task against which to compare proposals.

What is the difference between an auto-reply, a scripted bot and AI?

An auto-reply sends prepared text. It can be enough when a customer needs your opening hours or the next step. An automatic greeting should not count as a resolved enquiry: the actual question may still be unanswered.

A scripted bot guides someone through a known sequence. It might offer a language and service choice, collect the required details and pass the request to your team. Each step can have a defined expected action. The design also needs to handle people changing their mind, skipping a question or asking something outside the flow.

An AI bot using a knowledge base helps interpret free text and find answers in approved material. It needs defined sources, permitted actions and rules for involving a person. A confident answer is not proof of accuracy. Test the content against examples before launch and after updating the source material.

These approaches can work together. Rules check required fields, AI helps interpret a question, and a staff member handles an exception. Choose the mechanism for each step. A short, clear form does not automatically need to become an AI conversation.

What affects chatbot development cost?

The main factors are the scope of the conversation, preparation of source material and connections to working systems. Ask for setup and ongoing usage to be separated. Two proposals with the same service name may cover very different work, so comparing the final total alone can be misleading.

For the setup, clarify:

• Which questions and actions are included in the first release.
• Who prepares and edits the answer library.
• How many languages need preparation and testing.
• Which fields move to or from a CRM or calendar.
• What happens after an error, a repeated enquiry or a request for a person.
• Which tests, instructions and access handover are included.

Ongoing costs may include the platform, messaging, AI model usage, hosting and support. Which items apply depends on the architecture. The estimate should identify who pays each component, what changes the amount and who approves increased spending.

For a Dubai business, language coverage also affects scope. Three languages require the same agreed scenarios to be checked in each language. Arabic copy needs native-speaker review, with service names and terms checked against the company's material. Translation quality and integration behaviour are separate checks.

What does one booking scenario look like?

The following salon example is illustrative. It is not a client case study or a demonstration of a connected system.

A customer writes: “I'd like a haircut tomorrow after six.” The bot clarifies the service and preferred time, then collects the missing details through the agreed flow. From there, two different outcomes are possible.

Without a connection to the appointment calendar: the bot says, “I'll pass your preferred time to the administrator. Your booking is not confirmed yet.” The administrator receives the service, preferred time, reply contact and a status indicating that confirmation is needed. A person checks the calendar and continues the conversation.

With an agreed and tested calendar connection: the system retrieves available slots, offers a time and records the customer's choice. Confirmation can follow a successful booking operation. If saving fails, the customer must not be told that the appointment is booked. They need a clear next step and a handover to the responsible person.

In both versions, test a change of mind: “Actually, the day after tomorrow is better.” The flow should update the request, preserve context and avoid leaving the team with two conflicting enquiries. Testing this turn can reveal more than watching a demonstration of the expected conversation.

What should go into a chatbot project brief?

Prepare a short document that someone can read before a meeting. An initial discussion does not need passwords or your complete conversation archive. Anonymised examples and a list of systems are enough to start.

• Purpose: the part of your team's work you want to automate.
• Channel: where the customer starts and where an employee continues the conversation.
• Audience: the languages people use when contacting you.
• Scenarios: frequent questions, required fields and the intended outcome of each flow.
• Sources: current services, prices, terms and the person responsible for updates.
• Connections: existing systems and the specific information to read or write.
• Human handover: triggers, the responsible person and the information they need.
• Volume: available enquiry data and known busy periods.
• Boundaries: actions the bot should not take on its own.
• Acceptance: examples you will use together to check the result.

Mark anything you do not know yet. That makes it a specific question for the first discussion. For the wider process, read where an enquiry goes after the ad.

How do you assess a proposal and the finished flow?

Ask for the first release to be described as one complete journey, from a customer's message to an actionable request reaching an employee. Compare the proposal with your brief. Every promised outcome needs a way to check it, and every connection should be identified and assessed separately.

During acceptance, try an ordinary request, an unknown question, a language change, a changed choice and a request for a person. If an integration is included, test its unavailability too. Record what the customer sees, what reaches the team and who handles the failure.

After launch, useful measures include time to the first meaningful answer, completeness of collected details, handover reasons and flow errors. Fewer handovers do not automatically mean a better service: some questions belong with an employee. Enquiries and confirmed bookings also need separate counts.

BEIZ starts chatbot development for businesses with a process map and agreed scenarios. A prepared brief helps define the first release, required connections and estimate before choosing tools.