Connecting a chatbot to your CRM and ERP without a rebuild
The value of a bot is proportional to what it can look up. Most integration projects stall on the same three problems, all of which are visible before you start.
Key takeaways
- Establish whether a read path to the system of record exists, and what it costs, before committing to a timeline.
- A read-only replica or scheduled export proves the value far faster than a full integration.
- Normalise phone numbers on both sides, and never disclose account details on an unverified number.
- Start read-only on one entity and one question; full bidirectional integration in phase one is what stalls projects.
A chatbot's usefulness is bounded by what it can read and write. One that can check a real order, verify a real customer and record a real outcome is a service channel. One that cannot is a menu. Integration is therefore the project, and it usually stalls on three predictable problems: no usable interface to the system of record, no reliable customer identifier, and no agreement on who owns the data written back.
Problem one: the system has no interface
Many established ERPs in the region are on-premise, heavily customised, or accessed through a vendor who charges for every integration. Establish before committing to the project whether a read path exists, what it costs, and who can authorise it. If the honest answer is that order status lives in a spreadsheet a manager updates each morning, then the first phase of the chatbot project is making that data available, and the timeline should say so.
A workable interim pattern is a read-only replica or a scheduled export into a small database the bot queries. It is not elegant, it is much faster than a full integration, and it lets you prove the value before anyone commits to the larger work.
Problem two: identifying the customer
- The WhatsApp number is your identifier, and it may not match the number in the CRM. Numbers are stored with and without country codes, with leading zeros, and with formatting characters. Normalise on both sides before matching.
- One number may belong to several accounts, particularly for family or company purchases. Decide what happens then rather than letting the bot pick.
- A customer may message from a different number than the one on record. Have a verification path, usually an order number plus one other detail.
- Never disclose account information on an unverified number. This is the most common security failure in deployed bots.
Problem three: writing back
Reading is comparatively safe; writing changes your records. Decide early what the bot may create or modify, and prefer creating a record for a human to action over directly mutating a customer's account. A bot that can cancel an order needs a much higher confidence threshold and a clearer audit trail than one that can only log a cancellation request.
Sequence that de-risks it
Read-only first, on one entity, for one question. Prove the lookup is accurate against real orders before adding a second use case. Then add writing, starting with something reversible. Teams that attempt full bidirectional integration in phase one are the ones still testing six months later, because every edge case in the ERP surfaces at once and none of them was in scope.
A bot that cannot look anything up is a menu. Integration is not a phase of the project, it is the project.