← All guides
AI integration

Putting an AI Order Desk into a Decades Old ERP: What Actually Broke

6 min read

You run operations for a manufacturer or distributor. Your ERP has been running since before your current sales team was hired. It works. Nobody touches it. And now someone, maybe you, maybe the CEO, wants to put an AI layer on top of it so customers can place orders, check stock, and get quotes without calling your inside sales team.

I have built this. Here is what nobody tells you before you start.

The Real Problem When Putting an AI Order Desk into a Decades Old ERP

The AI part is not the hard part. The hard part is that your ERP was never designed to be talked to in real time by anything outside of it. Most systems this age expose data through one of three things: a file export that runs nightly, a COM or SOAP API that was bolted on in 2009 and never documented, or a direct database connection that your vendor's support contract explicitly forbids touching.

The AI order desk sits on top of all of that and has to answer a customer's question in under three seconds. Those two realities are in direct conflict from day one.

What Actually Broke in the Integration

Here is the honest list of where time went:

The data model was not what the docs said. Every ERP has a gap between how the documentation describes the schema and how it actually stores data after years of customization. Product codes had trailing spaces. Customer account numbers were reused after deletions. Price lists had override logic that lived in a stored procedure nobody remembered writing.

Stock numbers were stale by the time the AI read them. A nightly export means the AI is always working with yesterday's inventory. For some businesses that is fine. For anyone selling anything with real demand variance, a customer asks for 500 units, the AI says yes, and your warehouse has 12.

The authentication model was not built for per request calls. The old API issued session tokens that expired after 20 minutes of inactivity, which is fine for a human sitting at a screen and terrible for an AI agent that might sit idle between customer conversations.

Error messages were not designed to be read by software. When a stock check failed, the system returned a generic error string in the local language that meant three different things depending on context. The AI had to learn to interpret ambiguity, and that took more iteration than the original build.

Approval workflows broke immediately. Customers who had credit limits, special pricing, or account flags needed a human in the loop. The ERP knew about those flags. The AI did not, until we built a lookup layer that checked status before every quote.

Who This Work Is For and Who It Is Not For

This fits you This does not fit you
You process more than 30 to 50 repeat orders a week by phone or email You have fewer than 20 orders a week and a team that handles it fine
Your ERP has been running for 5 or more years and has some form of API or export Your ERP is still on a local server with no external access at all
Your customers are reordering known SKUs, not configuring custom products Every order requires a custom quote and a technical conversation
You are willing to give a technical contact 4 to 6 hours of their time for discovery You need this live in two weeks with no internal involvement

If you are in the left column, read on. If you are in the right column, this specific build is not the right use of your money right now, and I would rather tell you that here than after a scoping call.

If you already know you are in the left column and want to talk through whether your ERP can support this, reach out at ledianshera.com. I will tell you within one conversation whether it is feasible.

What the Build Actually Involves

This is the sequence I follow, and what each phase depends on:

Phase 1: Data audit (1 to 2 weeks). I get read access to your ERP environment, either a staging instance or a read replica. I map what data is available, how fresh it is, and what the pain points are. This phase exists entirely so Phase 2 does not blow up.

Phase 2: Middleware layer (2 to 4 weeks). This is the bridge between your ERP and the AI. It handles caching so stale data is labeled as such, normalizes product codes and customer IDs, and wraps the old authentication model into something stateless. Without this layer, you are building on sand.

Phase 3: AI agent build (2 to 3 weeks). The actual conversational layer. Scope of inquiry, stock checks, quote generation, order submission to a hold queue for human approval, and escalation routing. This is where the workflow for flagged accounts gets wired in.

Phase 4: Pilot with real users (2 weeks). Not a demo. Real customers, real orders, someone watching every session for the first week. This is where the edge cases show up: the customer who always uses an old part number, the account that has two pricing tiers depending on volume.

Total realistic timeline: 8 to 11 weeks from signed agreement to live pilot. Not two weeks, not six months.

The Objection I Hear Most Often

"We cannot risk breaking the ERP."

This is the right instinct and I take it seriously. The middleware layer is designed specifically so the AI never writes directly to your ERP until a human approves the order. Every transaction goes into a hold queue first. Your ERP sees a human approved input, same as it always has. The AI touches a read layer and a staging queue. That is the architecture I use precisely because the alternative, a live write connection to a 15 year old database, is not something I would recommend to anyone.

The ERP does not change. The data flow around it does.

What I Have Shipped and What That Means for You

I am the founder of AlbTech Solutions, where my team and I have built AI agents and full stack integrations for real businesses, not prototypes. The pattern above is the one I have refined across those projects. I am not selling you a framework I read about. I am describing the actual failure modes I have hit and the fixes that came out of them.

I do not pad timelines. I do not hide complexity. If your ERP audit in Phase 1 shows that a real time stock feed is not achievable without a vendor upgrade you are not ready to buy, I will tell you that before Phase 2 starts.

The Next Step

If you are looking at 30 or more phone and email orders a week that your team is processing manually, and you want to know whether your ERP can support an AI order desk, here is what happens when you reach out:

You send me a brief note at ledianshera.com describing your ERP (name and approximate age), your order volume, and the biggest bottleneck right now. I will respond within one business day with either a specific question to sharpen the scoping or a direct answer that this is or is not a fit. No sales deck, no discovery form with 40 fields. One conversation to find out if it is worth going further.

The readers who get value from this article and never reach out are not my target. You are, if you have the problem and the appetite to solve it properly.

Frequently asked

How long does it take to go live with an AI order desk on an older ERP?
Realistically, 8 to 11 weeks from signed agreement to a live pilot with real customers. The biggest variable is how accessible your ERP data is and whether a staging environment is available for the audit phase. Anyone quoting you two weeks has not done this before on a legacy system.
Will this require changes to our ERP or risk breaking it?
No changes to the ERP itself. The architecture uses a middleware layer that reads from your ERP and holds orders in a queue for human approval before anything is written back. Your ERP sees the same kind of input it always has. The AI never writes directly to a live system.
What does your team need from us during the build?
Primarily a technical contact who can grant read access to a staging instance or provide an export, and someone with business context who can answer questions about pricing rules, customer flags, and approval workflows. Expect 4 to 6 hours of that person's time across the first two phases, not a full time commitment.
What if our ERP has no API at all?
That comes out in Phase 1. Some systems can be reached through a direct database read or a scheduled export that feeds a real time cache. Some cannot support this build without a vendor upgrade. I would rather find that out in week one than week eight, which is exactly why the audit phase exists before any AI work starts.
Does the AI order desk work if our customers order in a language other than English?
Yes. The conversational layer can be configured for any language your customers use. The complexity is not the language itself but making sure your product data, error messages, and ERP outputs are clean enough to be parsed correctly. Multilingual setups add some prompt engineering time but are not a blocker.

Need a builder who ships?

I help founders and teams design and ship real software, fast. Full stack, AI, and everything around it.

Work with me