Avtomatlaşdırma

Chatbot and ERP Integration: How It Actually Works

A chatbot becomes genuinely useful the moment it can see real data: stock, prices, order status, outstanding balance. This guide explains what a bot can read from your CRM or ERP, what it may write back, and the three technical conditions every integration depends on. It also covers the cases where integration is not worth the work.

Chatbot and ERP integration means the bot reads live data from your accounting, CRM or ERP system and, in agreed cases, writes new records back into it. In practice it comes down to three conditions: an API the bot can call, a permission model that defines what the bot may touch, and a field map that connects the words customers use to the columns your database actually has.

Without integration a bot answers from a knowledge base. That is enough for opening hours, product descriptions and policy questions. With integration it answers the questions only your database knows: is this item in stock, where is my order, how much do I still owe. This guide explains both halves honestly, including the situations where integration is not worth the work.

What the bot can read from your database

Reading is the safe half of a chatbot CRM integration. Nothing changes in your system, so the worst possible outcome is a wrong or stale answer, not a corrupted record. Most of the business value sits here, and most projects should start here.

• Stock and availability — quantity on hand, per warehouse or per branch, so the bot never promises something you cannot ship.
• Price and discount rules — the current list price for a customer group, including an agreed rate that differs from the public one.
• Order and delivery status — where an order sits: accepted, packed, shipped, delivered, returned.
• Outstanding balance and debt — what a customer owes, when the invoice is due, which payments have already landed.
• Customer history — previous purchases, last service date, warranty end, so the bot does not ask questions the company already knows the answer to.
• Free slots — available appointment or delivery windows for booking-driven businesses.

Stock, price, order status, balance

These four are the classic chatbot database integration set, and they behave differently. Stock and price change constantly, so the bot must query them live rather than cache them overnight. Order status changes a few times per order, so a short cache is acceptable. Balance and debt are sensitive: the bot must confirm who it is talking to before it reads that number out loud, because an Instagram handle or an incoming WhatsApp number is not proof of identity on its own.

What the bot can write back

Writing is where an integration earns its keep and where it can hurt you. Every write should be narrow, logged and reversible. A useful rule: the bot may create drafts and requests freely, but it should not silently change money, stock or approved documents.

• Create a lead or a customer card when the person is new to the system.
• Create a draft order or a request that a human confirms before it becomes a real document.
• Book an appointment in a slot the bot has already verified as free.
• Open a ticket or a complaint with the conversation attached as evidence.
• Update contact details such as a delivery address or an alternative phone number.
• Write the conversation log back to the customer card so the sales team sees the full history.

Read versus write: a practical comparison

Aspect	Read-only integration	Read and write integration
Typical data	Stock, price, order status, balance	Leads, draft orders, bookings, tickets
Risk if the bot is wrong	A wrong answer in chat	A wrong record inside your accounting system
Access needed	A read-only API user or a view	A scoped account with create rights only
Human control	Usually none needed	Confirmation step or live agent handover
Build effort	Lower — start here	Higher — add after the read side is stable
Good first use case	Order tracking by order number	Draft order from a repeat customer

The three conditions every integration depends on

1. An API, or a database the team controls

The bot needs a documented way in: a REST or GraphQL endpoint, a webhook, a stored procedure, or at minimum a read-only view on the database. If your ERP is a closed desktop product with no interface, integration becomes an export and import routine instead of a live query, and answers will only be as fresh as the last export. Ask your vendor for the API documentation before you plan anything else — that single document decides the whole scope.

2. Permissions and limits

Give the bot its own account, never a manager login. Grant the narrowest scope that does the job: read stock, read orders, create leads, nothing more. Add a rate limit so a burst of chat traffic cannot slow your ERP down, and log every call with a request identifier. If the bot may read financial data, define the identity check first: an order number plus a phone match, or a one-time code sent to the registered number.

3. Field mapping

Customers do not speak in column names. Someone writes "the black one, size 42" and your database holds an SKU. Field mapping is the translation layer: product names and synonyms to SKU, branch names to warehouse identifiers, status codes to sentences a customer understands. This is usually the longest part of the project and it is unavoidable. A bot with perfect API access and a poor field map still gives poor answers.

Why one team for the chatbot and the accounting system helps

When the chatbot vendor and the ERP vendor are different companies, much of the schedule is spent waiting: waiting for endpoint documentation, waiting for a test account, waiting for someone to explain why a status code means something other than its name. Each side also has an incentive to say the problem belongs to the other side.

When the same team builds both, the API is designed with the bot in mind, the field map is written once, and a change in the data model reaches the bot in the same release. AI Media works this way: we build AI chatbots and ERP or industry systems as services under one roof, and we run our own systems in production, including manufacturing control, poultry and farm accounting and carpet cleaning operations. Our own record so far is 387 clients and 478 projects; the verifiable company facts are listed on the English company profile.

The chat side runs on our NERO platform at app.aimedia.az: Instagram DM, WhatsApp, Facebook Messenger and website chat in one inbox, a visual flow builder, a knowledge base of up to one million tokens, saved replies, live agent handover, team roles and analytics. Bots are built inside the panel itself, so no n8n, Make or Zapier layer sits between the chat and your data, and the website widget is generated in the same panel as a single snippet. WhatsApp connects either through the official Cloud API or by QR, and there is no language limitation — the bot detects the customer language and replies in it. A standard chatbot is built and handed over in one hour once your content is ready; the integration is the part that takes real project time. The rest of the product family is on the products page, and the packaging is described on the plans page.

When you do NOT need integration

Integration is a cost, not a badge. Skip it, at least for now, when any of the following is true.

• Your catalogue is small and stable. Twenty services that rarely change belong in the knowledge base, not behind an API.
• Your data is not trustworthy yet. If stock in the system does not match stock on the shelf, integration will publish that error to every customer instead of hiding it.
• Most questions are not data questions. If people mainly ask where you are, what you do and how long a job takes, a knowledge base answers all of it.
• The system has no interface and no roadmap for one. A nightly export can be a reasonable stopgap while you decide.
• Nobody owns a wrong record. Write access without a named owner is a governance problem, not a technical one.

Common mistakes

Three failures repeat across projects. The first is giving the bot write access on day one, before anyone has watched how it reads. The second is skipping identity checks on balance and order data, which turns a helpful bot into a data leak. The third is treating field mapping as a small task and discovering three weeks later that half of the product names used in chat have no match in the catalogue.

A realistic rollout order

1. Collect the API documentation and create a read-only test account.
2. Ship the knowledge base bot first, with no integration at all, and read the real questions people ask.
3. Add one read use case — usually order status by order number — and measure how often the answer is correct.
4. Add the remaining read data: stock, price, and balance behind an identity check.
5. Only then add one write use case, with a confirmation step or handover to a live agent.
6. Review the logs every month and retire anything the bot answers badly.

This order keeps every step reversible. If a use case fails, you switch it off and the rest of the bot keeps working, because the chat layer and the data layer stay separate.

Next step

Send us the name of your CRM or ERP and the three questions your customers ask most often. We will tell you which of them can be answered from your data today, which need field mapping first, and which do not need integration at all. Write to us on WhatsApp or through the contact page, and you will get a scope you can check line by line.