How to Build an AI WhatsApp Chatbot in Nigeria: A Step-by-Step Guide

This is a build guide. It is written for a Nigerian business owner or manager who wants to understand each step well enough to do the simpler parts themselves, brief a developer properly, or evaluate a vendor's proposal. It does not assume you can code, but it explains what the code has to do.

The three routes (Cloud API directly, a BSP, or a no-code platform) share the same first steps and diverge at the build stage. The comparison in step 4 will help you pick.

Before you build: what a WhatsApp chatbot needs

A working AI WhatsApp chatbot has a fixed set of parts regardless of who builds it.

Keep this table in mind when reading vendor proposals; every part should be accounted for.

Step 1: Define scope and design the conversations

The first step is to decide what the bot will and will not do. Ambitious scopes fail; narrow scopes launch.

1. List the top ten message types from two weeks of real WhatsApp conversations: price checks, availability, delivery, payment proof, order status, complaints, custom requests.
2. Choose the three to five the bot will handle at launch. Typical launch scope: price and availability answers, delivery information, order capture, and handoff for everything else.
3. Write the conversation flows for each in plain language: what the customer might say, what the bot asks, what it needs to look up, how it ends. Include the mixed English and Pidgin variants your customers actually use.
4. Decide the persona and disclosure. Name the assistant, state that it is automated, define the tone (polite, concise, Standard Nigerian English), and write the "talk to a person" wording.
5. Define the escalation triggers. Requests for a human, anger signals, money disputes, anything outside scope.

Write all of this in a document. It becomes the specification for the developer or the configuration for a no-code platform.

Step 2: Prepare the knowledge base

The knowledge base is what the AI answers from. If it is incomplete or stale, the bot will be wrong regardless of the model.

• Products or services: name, variants, price, availability, short description. A spreadsheet is fine to start; a database is better when the catalogue is large or changes daily.
• Delivery: zones or cities, fees, timelines, partner names, cut-off times.
• Payments: accepted methods, account details for transfer, gateway links, confirmation process.
• Policies: returns, exchanges, warranty, cancellations.
• Business identity: CAC registration, address, opening hours, contacts, social handles. Customers ask.
• FAQs: the actual questions with approved answers.

Two rules: date every price list and assign one person to update it; and write answers the way you would want them said to a customer, because the model will paraphrase what it is given.

Step 3: Set up Meta Business, verification and the number

WhatsApp chatbots run on the WhatsApp Business Platform, which requires a Meta Business account. Requirements change; follow Meta's current documentation.

1. Create or confirm your Meta Business account (the same one used for Facebook and Instagram advertising).
2. Complete Business verification. Meta typically asks for business registration documents (CAC certificate) and proof of address or phone. Verification raises your messaging limits and makes the official business account tick available on application.
3. Choose the phone number. It must not be active on the WhatsApp or WhatsApp Business app at the same time. Options: a new dedicated line, or migrate your existing business number (which then stops working in the app). Many Nigerian SMEs buy a new SIM for the Platform and forward customers gradually.
4. Create the WhatsApp Business account in Meta Business Manager (or through your BSP), register the number and set the display name, profile and business description.
5. Note the messaging limits. New numbers start with limits on business-initiated conversations that rise with volume and quality.

Step 4: Choose your build route

The difference between the three routes is control versus speed.

A practical rule: if your bot needs your own data, custom integrations or strict data control, choose a BSP or the Cloud API with a developer. If you need something live in weeks and your scope is simple, a no-code platform is reasonable, and you can migrate later.

Step 5: Build the message backend

For custom routes, the backend is the software that receives and sends messages. In business terms it must:

1. Receive webhooks. When a customer sends a message, Meta (or the BSP) calls your server with the message content. The server must respond quickly and reliably, so it is hosted on a cloud server or VPS with a public HTTPS address, not on an office computer.
2. Verify and log. Confirm the webhook is genuine, store the message, and record the conversation.
3. Manage state. Track where each customer is: mid-order, awaiting address, escalated. A database (PostgreSQL, MySQL, or a managed equivalent) holds this.
4. Decide the next action. Rules for structured steps (confirm order, send template); the AI layer for understanding and composing.
5. Send the reply through the API: text, buttons, list messages, images, or a template outside the service window.
6. Handle errors and retries. Messages fail; the backend should retry and alert.

Hosting typically sits in the ₦150,000–₦800,000 per year band for a VPS or small cloud instance, indicative and depending on load.

Step 6: Build the AI layer

The AI layer turns a customer's words into a correct, on-brand answer. A reliable design has four elements.

System instructions. A written brief given to the model with every request: who the business is, tone, what the bot may and may not do, how to handle pricing, when to escalate, and an instruction to answer only from provided information and to say when it does not know.

Retrieval (RAG). Rather than pasting your whole knowledge base into every request, the system finds the passages relevant to the customer's message (using vector search or a structured lookup for prices) and passes only those to the model. This keeps answers accurate and costs down. Structured data such as prices and stock should be looked up directly, not retrieved as text.

Intent and extraction. For orders and bookings, the model extracts structured fields (product, quantity, address, date) that the rules then act on. Ask the model for structured output so the backend can validate it.

Guardrails. Confidence checks, a list of forbidden topics, a rule that the model never confirms payments or invents prices, and automatic escalation when the retrieved information does not answer the question.

Choosing a model: any of the major providers works; choose on cost per message, response speed, and support for the languages your customers use. Test Pidgin and mixed-language messages specifically. Keep the option to switch providers by not tying business logic to one API.

Step 7: Add handoff, templates and integrations

Handoff. Connect the bot to a shared inbox (your BSP's, a helpdesk, or a simple internal tool). When escalation triggers fire, the bot tells the customer, tags the conversation, attaches a summary and notifies a person. Staff must be able to pause the bot on a conversation and resume it.

Templates. For business-initiated messages (order confirmations, dispatch updates, reminders), write and submit templates for Meta approval in the right category (utility or marketing). Collect and record opt-in before sending marketing templates.

Integrations. Start with one or two:

• Payments: Paystack, Flutterwave, Monnify or similar payment links, with webhooks that confirm payment and trigger a receipt.
• Orders or bookings: write confirmed orders to your sheet, order system or calendar.
• CRM: create or update the contact with what they asked and bought.

Each integration should be built so that a failure (gateway down, sheet unreachable) results in a graceful message and an alert, not silence.

Step 8: Test with real messages

Testing separates working bots from embarrassing ones.

• Collect at least 100 real customer messages (anonymised) covering all launch flows, including Pidgin, typos, voice-note transcriptions and screenshots.
• Run each through the bot and score the answer: correct, partially correct, wrong, correctly escalated.
• Test adversarial cases: asking for discounts, asking about competitors, asking for medical or legal advice, trying to get the bot to confirm a payment, sending abuse.
• Test the handoff end to end: does a person receive the summary and can they take over?
• Test templates: are they approved and do they send outside the service window?
• Test integrations with real (small) payments and orders.
• Test on poor connectivity: does the bot cope with delayed or duplicated messages?
• Review costs: how much did the test conversations cost in AI usage, and what does that imply per month?

Fix the knowledge base and prompts until wrong answers are rare, then run the whole set again.

Step 9: Launch, monitor and improve

1. Soft launch to a subset of customers or a specific hour range, with a person watching the inbox.
2. Monitor daily for the first two weeks: error logs, escalations, wrong answers, AI cost.
3. Review transcripts weekly and add missing answers to the knowledge base.
4. Set usage caps on the AI provider and alerts on Meta charges to avoid surprises when the exchange rate moves.
5. Expand scope one flow at a time once accuracy is stable.
6. Document the system: where the knowledge base lives, how to update prices, how to pause the bot, who to call when it breaks.

Example (hypothetical): a Lagos auto parts dealer

Example (hypothetical): a spare parts dealer with a shop in Ladipo and a warehouse in Ikeja sells to mechanics and car owners across Nigeria. Messages arrive as "do you have front bumper for Corolla 2012?", photos of parts, and voice notes. Staff answer the same fitment and price questions all day, and orders are lost in the volume.

The build:

• Scope: part availability and price lookup, delivery quote by state, order capture with payment link, handoff for photos, voice notes and anything unclear.
• Knowledge base: a parts spreadsheet with make, model, year range, part name, price and stock, updated daily by the warehouse; a delivery table by state through a logistics partner; policies for returns on wrong fitment.
• Route: a BSP for the Platform and inbox; a custom backend built by a developer; an LLM for understanding messages, with prices looked up directly from the spreadsheet rather than generated.
• AI layer: extracts make, model, year and part from messy messages; asks a clarifying question when the year is missing; escalates photos to staff (with an option to add image recognition later).
• Integrations: Paystack payment links with webhook confirmation; confirmed orders written to the order sheet; dispatch template on shipment.
• Testing: 150 real messages, including Pidgin and voice-note transcriptions; the main fixes were adding common nicknames for parts and handling "how much last" negotiation attempts with a polite fixed-price answer.

The dealer launches with the bot handling lookups and orders during and after shop hours, and staff handling photos and negotiations. The point of the example is the design decision to look prices up rather than let the model state them, and the decision to escalate images rather than guess.

Costs and timeline by route

Indicative 2026 ranges; actual quotes vary with scope, vendor and exchange rate. Compare two or three written quotations on identical scope.

What a good custom quote includes: discovery, conversation design, knowledge base setup, backend, AI layer, one or two integrations, handoff, testing on real messages, launch support and a warranty period. What is usually extra: Meta verification handling, additional integrations, ongoing content updates, and all third-party fees.

Mistakes to avoid

• Skipping the conversation design. Building before defining scope produces a bot that tries everything and does nothing well.
• Letting the model generate prices. Look prices up from data; the model only phrases the answer.
• No retrieval, just a giant prompt. Slow, expensive and inaccurate as the knowledge base grows.
• Hosting the webhook on an office machine. Power and connectivity failures take the bot down. Use cloud hosting.
• Testing only with your own tidy messages. Real customers send typos, Pidgin, voice notes and photos.
• Forgetting Meta's rules. Unapproved templates and missing opt-in stop your messaging.
• No pause button. Staff need to take over a conversation and silence the bot for that customer.
• No cost caps. AI usage in US dollars can spike with volume or a looping conversation.

Conclusion

Building an AI WhatsApp chatbot in Nigeria is a sequence: scope and conversation design, a maintained knowledge base, Meta setup and a dedicated number, a build route that matches your need for control, a backend that handles messages reliably, an AI layer that retrieves facts rather than inventing them, a working human handoff, careful testing on real messages, and monitoring after launch. Do the first three steps yourself even if a vendor builds the rest; they determine whether the bot is useful.

If you would like a developer to take your conversation design and knowledge base through to a tested, launched WhatsApp chatbot with the integrations your business needs, Linestech can scope the build with you.

Frequently asked questions

Can I build an AI WhatsApp chatbot without coding?

Yes, for simple scopes: no-code chatbot platforms provide the Platform connection, a visual flow builder, an AI answer feature trained on your documents and a shared inbox. You will still need to complete Meta verification, write the knowledge base and test thoroughly. Custom data lookups and integrations usually need a developer.

Which AI model should I use for a WhatsApp bot?

Any major provider's current models can power a WhatsApp bot. Choose based on cost per conversation, response speed, and performance on your customers' language mix, which you should test directly. Design the system so the model can be swapped; prices and capabilities change frequently.

How do I connect the chatbot to Paystack or Flutterwave?

The bot sends a payment link generated through the gateway's API. When the customer pays, the gateway calls your backend's webhook; the backend marks the order paid and the bot sends a receipt. Follow the gateway's developer documentation and test with small live transactions before launch.

Do I need Meta verification before building?

You can build and test with a limited setup, but for production use, higher messaging limits and the official business tick you need a verified Meta Business account. Start verification early because it can take time and may require CAC documents and proof of address; check Meta's current requirements.

Can the bot handle voice notes and photos?

With additional components, yes: transcription models convert voice notes to text, and vision-capable models can describe images. Both add cost and complexity. A sensible launch approach is to escalate voice notes and photos to a person, then automate them once text conversations are stable.

How do I keep the bot from answering things it should not?

Give it explicit instructions on forbidden topics, restrict it to retrieved information, add escalation rules for low confidence and sensitive topics, and test adversarial messages before launch. Review transcripts weekly and tighten the instructions when you find gaps.

Where should the chatbot be hosted?

On a cloud server or VPS with a public HTTPS address and reliable uptime, not on an office computer. Nigerian or international cloud providers both work; consider data-protection requirements under the Nigeria Data Protection Act 2023 when choosing where customer data is stored.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.

• Corporate Affairs Commission (CAC)
• Nigeria Data Protection Act 2023 — NDPC
• Paystack developer documentation
• Flutterwave developer documentation
• WhatsApp Business Platform — Meta for Developers
• Node.js documentation
• PostgreSQL documentation