AI in ERP Systems and CRMs: Where It Helps and Where It Decorates

There is a straightforward test for any AI feature in business software, and most features fail it: can it see your data, and does it remove a task a person is doing repeatedly today? AI in ERP systems is worth building when the answer to both is yes — a new user who cannot find the goods-receipt screen, a salesperson reading four screens before a call, a clerk typing the same reply for the ninth time this week. When the answer is no, what you have is a chat box that makes the software look modern in a demo and gets closed within a fortnight. This piece separates the two, because vendors rarely do.

Where AI in ERP systems genuinely helps

Onboarding: the system explains itself

The most reliable win we see has nothing to do with prediction. Business systems are large, and every new employee spends their first weeks asking a colleague where things are — which interrupts two people at once. An assistant trained on your own configuration, screens and written manuals lets that person ask in plain language: how do I raise a purchase order against a buyer PO? It answers from your documentation, names the screen, walks the steps.

This matters most in operations where staff turnover is a fact of life. It is the same principle behind the written manuals we hand over with every system, institutional memory that does not leave when someone resigns, except the manual now answers questions instead of waiting to be read.

The summary before the conversation

Before a call with an account, someone assembles context: open orders, delivery history, ledger balance, the last complaint, what was promised. In a system where all of that lives in one database, an assistant can compose that briefing in the seconds before the phone is picked up. In a business running a separate CRM and a separate ERP, it usually cannot — which is one more argument for keeping CRM and ERP on one system rather than syncing two.

The routine reply, drafted not sent

A great deal of correspondence is genuinely routine: order acknowledgements, delivery-date questions, statement requests, the sixth follow-up about a pending document. An assistant that drafts these against the actual record, in the house style, and leaves them for a person to glance at and send, converts writing into approving. The distinction matters (drafted, then approved) and it is a deliberate design choice, not a limitation to be engineered away later.

Flagging what looks abnormal

Systems already hold the history that makes an exception visible: an invoice far outside a customer’s usual range, a production batch losing more weight at a stage than that stage normally loses, a party balance that has aged past everything else on the ledger. This is not fortune-telling. It is comparing today against your own record and raising a hand — the sort of check a very attentive employee would do if they had time to read everything, and never does.

The report that was never commissioned

Between the standard reports and a formal request to the vendor sits a large class of questions that never get asked, because asking used to be expensive: which parties took longer to pay this quarter than last, which product carried most of the discounting, which stock has not moved since winter. An assistant that translates a plain-language question into a query against the same database (and shows the query it ran, so the answer can be checked rather than believed) turns each of those from a request into a sentence. It is also the capability that most rewards a single database: a question spanning sales, stock and receivables can only be answered where those records live together. The caveat is the same as everywhere else in this piece: the answer is only as reliable as the records underneath, and the assistant must refuse questions the asker’s role is not entitled to have answered.

Where it only decorates

A chat box that cannot see the data. The single most common feature shipped under the word “AI”. It sits in the corner, answers from general knowledge, and cannot tell you what is outstanding on account 214. If an assistant is not retrieving your documents and querying your records under the asking user’s permissions, it is a novelty; the difference between the two is explained in our piece on retrieval-based chatbots.

Prediction on too little history. Forecasting is the feature most requested and least often justified. It needs a long, clean, consistently recorded history and a pattern that has not fundamentally changed. A business that reorganised its product lines last year, or whose staff record the same transaction three different ways, will receive confident numbers with nothing behind them — and confident numbers are worse than none, because people act on them.

Insights nobody acts on. A paragraph of generated commentary above a dashboard — “sales increased compared to the previous period” — describes what the chart already showed. If the output does not change a decision or remove a task, it is text.

AI as a workaround for bad design. If users need an assistant to find a screen because the navigation is incoherent, or to construct a report because the reporting is unusable, fix the system. An assistant papering over a structural problem adds a second thing to maintain.

The questions to put to any vendor

Ask what data the feature reads, and whose permissions it reads under. Ask it to answer a question about your own records, live, in the demo — not a scripted one. Ask what happens when it does not know: silence, invention, or a clean handover to a person. Ask how its knowledge gets updated when a policy changes next month, and who does that. And ask which task, precisely, disappears from someone’s day — if the vendor answers in adjectives rather than naming the task, there is nothing there.

One more question, asked less often in Pakistan than it should be: where does the data go? An assistant can be built so that records stay in your database and only the material needed for a specific answer is processed, or it can be built to ship your ledger wholesale to a third party. Ask which of the two you are being sold, what is retained afterwards and where, and expect the answer in writing. A vendor who cannot say has not thought about it, and that is an answer too.

What has to be true underneath

An assistant is only as good as the system beneath it. Three foundations decide whether this works at all.

One database. If your records live in several systems that reconcile overnight, an assistant reads a version of the business that is hours old and internally contradictory. Systems where production, sales, inventory and accounting write to one database — the shape of the ERP work we do — give an assistant something coherent to read.

Enforced permissions. The assistant must inherit the user’s access, not the administrator’s. Row-level and column-level security in the database means the answer a branch manager gets is scoped to their branch even when the question was phrased cleverly.

A record of what it did. Every draft it wrote, every query it ran, every escalation. Not for ceremony — because the first time an answer looks wrong, you need to see what it was answering from. An assistant that cannot show its working is a rumour with a user interface.

How we add it

We do not begin with the technology. We begin by watching which repeated task is actually costing hours, on-site where we can, and then say whether AI is the right instrument for it — sometimes the answer is a better report, or an automated workflow with no model involved at all. Where it is the right instrument, it goes into the specification you approve before development, gets built against your own data, and gets trained into your team role by role like any other module. The first candidate should be deliberately small — one task, one role, measured — because a small assistant that visibly works buys the patience the larger ones need. Systems we did not originally build can often take an assistant too, provided the source code is available and the data model holds up; we will tell you honestly if it does not.

If there is a task in your ERP or CRM that a person repeats every day and dislikes, that is the conversation worth having. Describe the task and we will tell you whether it is a genuine candidate — or whether we would be selling you decoration.