Everyone will have AI. Very few will have encoded how their business actually works.
Manufacturers and distributors do not exist to operate software. They exist to make and move the products their customers need, deliver amazing customer service, and expand into new markets where they can meet demand.
To succeed, they need to build a business that keeps doing it over and over again, profitably.
Until today, that has had a hard limit: people. More orders meant more operation, and more operation meant more people. Human capacity has been the bottleneck on growth, and the cost of carrying it has been one of the largest a business takes on.
That is where I believe the conversation about enterprise AI should begin. Not with what a model can do, but with what we want the operation to become capable of.
I believe AI will become widely available much faster than most companies expect. Reading a purchase order, matching product codes, preparing a quote, or pulling a transaction from the ERP will not remain a lasting advantage on its own.
These capabilities matter when they help someone serve a customer, keep a commitment, or make a better decision. Connecting them to the business is the harder work.
Giving AI access to your systems is not the same thing as giving people and AI a better way to run the operation.
More tools are not the goal
Industrial companies have invested in ERP systems, monitored machines, moved infrastructure to the cloud, and reorganized software around services.
Those programs delivered value. Records, controls, infrastructure and integration matter. What they did not deliver was operational value. They were expensive and complex, and the gap between what the technology could do and what the operation actually needed stayed wide open. That gap is why so many of them are remembered as bad projects.
There is a reason it keeps happening. The business buys a tool, and then asks its people to bend the process they wanted around it. The outcome was clear. How, where and when to use the tool to get there was left to each person to work out. That is why the same process ends up being run three different ways by three different people.
If we change nothing, AI repeats it. Another tool, the same improvisation, at higher speed.
But there is an opportunity here that did not exist before. We can define the process we want and have it run exactly as intended, calling the tool behind it when it is needed. The tool used to dictate the process. Now the process can dictate the tool.
The question was never how much technology a company can deploy. It is whether that technology actually delivers operational gain.
The work between the systems
Take order creation. Sales is the blood of a business, and this is where customer intent becomes an operational commitment.
Recording the products and quantities is the easy part. Someone must understand what the customer means, whether the proposed product fits the application, and what the business can actually promise.
Consider a familiar request: a customer uses an old product name, asks for the same configuration as a previous purchase, or needs an alternative to an unavailable item. The information in the request is not enough. The person handling it needs the history and the reason behind the choice.
That is the first problem. The operational knowledge required to do the work correctly lives nowhere in the systems. It is in customer conversations, in experience, in the judgment of the person everyone asks when the answer is unclear.
The second problem is the systems themselves. To complete a single task, a person moves across legacy applications, several of them, where rules and conditions are buried in custom code no agent can find. They have to know which system to use, when, and how. That knowledge is not written down either.
The same two problems appear in planning, procurement, production, logistics and customer service. The task changes. The gap does not.
An agent can have access to every record and still be missing what it takes to act responsibly.
Expertise should outlive the expert
Until now, people have been the most valuable asset in an industrial business, and for a good reason: they hold the operational knowledge and the expertise the company runs on.
That is also the risk. When the expertise walks out, the knowledge walks out with it.
What is new is that we can now turn that knowledge into something else. Operational knowledge is not static. It changes with every customer, every exception, every correction. For the first time, that ever-evolving expertise can become an asset the business owns and the whole organization can draw on. I believe the companies that build that asset first will hold an advantage the others cannot buy.
Think about how a person actually learns the job. Not from a manual. They learn by using the tools, by doing the work, by picking up context, by making mistakes and being corrected. Expertise is built through use.
A system should learn the same way. You can capture some knowledge in workshops and documentation, but it is impossible to capture everything in advance. Some of it only becomes visible when someone corrects a recommendation or explains why the usual answer will not work.
Every correction is an opportunity to keep that understanding. Who made it? What was the reason? Does it apply to this order, this customer, or a wider set of situations? What needs to be validated before anyone relies on it again?
Capturing an answer without its scope just makes the wrong answer easier to repeat.
This is why the technology has to be present where the work happens. The aim is to make the next person better equipped, instead of asking them to rebuild the same knowledge from scratch.
We have seen what that changes. In one deployment, it took 24 hours of training just to take an order. It now takes under an hour.
That is a training result, and it points at something larger: expertise becoming available at the moment of work. Training still matters. People still develop judgment. But a business should not have to rebuild access to its own knowledge with every new hire.
The human is not the fallback
There is a tempting story about AI adoption: first the human is in the loop, then on the loop, and eventually there is no human at all.
That is not the ambition I would choose for a critical industrial operation, because replacing people was never the point.
The point is to use human capacity to its full potential. Every task that is unnecessary, repetitive, or creates no value should come off a person's desk. What remains is the work that deserves them: the customer, the trade-off, the judgment call. People will still be needed, and in the areas that matter most they will be needed more than ever.
So some work should be automated. Some should be prepared by AI and approved by a person. Some should follow a fixed, predictable process. Sometimes a familiar interface beats a conversation with an agent.
The goal is not to maximize the percentage of work performed by AI. It is to increase what the operation can do, and what its people are free to contribute.
That takes more than giving an employee another assistant to ask questions. People and AI need a shared place to do the work. The person should see what is being proposed, which information supports it, what remains uncertain, and what happens if they approve. They should be able to correct the proposal without losing the context or starting over somewhere else.
A salesperson's read on a customer, a planner's judgment about a commitment, an employee's relationship with a vendor: none of that is an obstacle to automation. It is part of what the business sells.
The human is not the fallback. The human is part of the operating model.
The operation should improve itself
Here is what I think we have gotten wrong for a long time. Operational improvement has been treated as an IT project, when it is a business decision that belongs to each department.
The people who run an operation know exactly what is broken and what could be better. They always have. What they never had was a way to act on it. Every fix had to be translated into a requirement, queued behind other priorities, handed to a team that does not live the problem, and delivered months later as something that had drifted from the original intent. That is where the misunderstandings between teams come from. That is why adoption fails.
So the ambition is an operation that improves itself. A system that recognizes when the same clarification is needed over and over, when a recommendation keeps getting corrected, when an approval adds delay without changing the decision, and can propose the change. Then the department that owns the work decides whether it helps.
The measure is not whether an agent completed a task. It is whether the customer received the right product, the commitment was kept, or the team stopped losing time on the same avoidable problem.
Over time, I believe part of that improvement can happen on its own, inside boundaries the business has approved. Other changes will still need human judgment, testing, or technical review. Autonomy has to grow out of reliable context, explicit permissions, and evidence that the change helps. A system should never mistake one person's workaround for a rule everyone must follow.
IT keeps an essential role in security, access, architecture, and the controls that make any of this possible. What changes is that improving an authorized rule no longer requires opening a project.
Build around the operation
This is what we are building at Frontleap: an intelligent execution layer for manufacturers and distributors.
It brings three responsibilities together around the work.
Capture the operational knowledge that lives nowhere in your systems.
Give people and AI one place to act on it together.
Give the operation the power to improve, learn, and grow on its own.
Those three belong together. Knowledge capture without action becomes another repository nobody opens. An AI interface without context leaves people checking every answer. Improvement without outcomes optimizes activity instead of the business.
The ERP remains essential. Frontleap runs alongside SAP without modifying it. We build on the systems companies already trust, and change how people and AI work with them.
We start with orders, because that is where the connection to the customer is immediate. What did they ask for? What can we commit to? What needs to happen next?
The future we are building
People and agents working side by side on the same task, each taking the part they do best, and the work getting done the most efficient way available.
Operational knowledge, business rules, and the conditions behind them no longer living in people's heads, but held as a lasting asset the entire business draws on.
The operation in control of the tools and systems it uses, so the software that runs the work is genuinely built for the work.
The operation learning as it performs, uncovering opportunities it could not see before, and growing its own expertise with every task completed.
Core systems improved, optimized, or replaced underneath, without ever changing how the work is done on the floor.
That is not a thought experiment. That is exactly what we are building.
Technology should serve the operation. It should make the business more efficient. It should not dictate how the company operates.
The models will be everywhere. The agents will become commonplace. What your business knows about how it actually works will not.
Find out what your operation knows
Bring one workflow that depends on your most experienced people. In one working session, we map the knowledge it runs on, where that knowledge lives today, and what could be encoded first.
Book a working sessionAuthors
Read more
Frequently asked questions
What is Frontleap, exactly?
Frontleap is an AI-powered order management platform built for manufacturers and distributors on SAP. It adds an execution layer on top of the ERP to simplify and automate order work. Your ERP stays the system of record; Frontleap is where the work actually happens — order entry, product search, inventory lookup, document access — in an interface built for the people doing it. Nothing is duplicated and nothing is replaced: we hold the last 20% of the ERP, the part your teams currently handle with spreadsheets, email and workarounds.
Do we need to replace or modify our ERP to use Frontleap?
No. Frontleap runs alongside your existing ERP, without modification to your core systems. Your ERP keeps operating exactly as before, and your IT team keeps full control of its configuration and security. We don't rip and replace anything — we sit on top and send clean, validated transactions back into the system of record.
How long does implementation take and what's involved?
Most deployments run one to three months, in three steps: connecting to your existing systems, configuring the workflows your business actually uses, then a pilot with one team before wider rollout. We deploy progressively — one location or department first, expanding once it's proven. No disruption to daily operations.
Is Frontleap secure and compliant?
Yes. Single sign-on with your existing identity provider, role-based access controls, encrypted transmission. We don't store your sensitive business data — we read it in real time from your secured systems. Everything stays inside your existing security perimeter and compliance frameworks.
What can Frontleap handle?
Order entry and modifications, product search and inventory lookup, quote generation, returns and credits, customer account management, access to specs and pricing documents, multi-location stock visibility. In practice: anything where someone has to jump between screens or systems to get one job done.
Why not just improve our current ERP?
Because the problem isn't your ERP — it's the distance between it and the people using it. ERP projects deliver the system of record; they rarely deliver adoption at the counter. Frontleap runs independently of your ERP version, so it doesn't break with upgrades, and your teams are productive in a fraction of the usual ramp-up.
Does Frontleap work on mobile and in-store devices?
Yes, any device with a browser. Desktop, tablet, phone. The interface adapts to the screen, and works with the hardware already on your floor, like scanners and receipt printers. Your teams can look up stock, build orders and process transactions from anywhere in the building.
What is AI-assisted order entry for SAP?
AI-assisted order entry uses AI to interpret an incoming customer request, map it to the products and information stored in SAP, identify missing or uncertain information, and prepare the sales order before a representative approves it. With Frontleap, the AI works alongside the existing ERP rather than replacing it. SAP remains the system of record, while Frontleap handles the operational work required to turn an unstructured customer request into a clean, validated transaction.
How does Frontleap turn an email or PDF into an SAP order?
Frontleap reads the customer request from an email, PDF or information captured during a call and identifies the products, quantities and other order details it can determine. It then resolves those details against your catalogue and relevant ERP context, including stock, pricing, customer information and previous orders. Instead of guessing when information is unclear or missing, Frontleap surfaces the exception to the representative. The rep reviews the prepared order and approves the clean transaction before it reaches SAP.
Can Frontleap understand customer product names that do not match SAP material numbers?
Yes. Frontleap is designed for the gap between how customers describe products and how those products are represented in the ERP. A customer may use an abbreviation, an old part number, a local nickname or a description such as “the usual 12 inch.” Frontleap uses catalogue information and operational context to resolve that language to the appropriate product. When there is not enough information to make a reliable match, it asks the representative rather than silently selecting a material.
What does Frontleap validate before an order reaches SAP?
Frontleap can use the information surrounding the transaction — including catalogue data, inventory, pricing, customer account information, previous orders and business context — to prepare the order before it reaches SAP. The objective is not simply to extract fields from a document. It is to determine whether the order is ready to process and identify what still requires a human decision. Missing information, uncertain matches, pricing questions and other exceptions remain visible to the representative for review.
Does Frontleap create SAP orders automatically, or does a representative approve them?
Frontleap is designed around human approval where a business decision is required. The AI prepares the order, resolves what it can from your systems and operational knowledge, and isolates the exceptions that genuinely need attention. The representative can then review, correct and approve the result before the validated transaction is sent to SAP. This allows teams to automate repetitive order preparation without asking an AI system to make business decisions that should remain with the people operating the desk.
Does Frontleap replace SAP or require changes to our ERP?
No. Frontleap runs alongside SAP rather than replacing it. SAP remains the system of record for the transaction, while Frontleap provides an execution layer where frontline teams can prepare orders and make operational decisions. This separation means the order desk can get a simpler, task-oriented workspace without turning the initiative into another ERP replacement project. Frontleap connects to the existing enterprise environment and sends validated transactions back to the system of record.
How long does it take to implement Frontleap Order Desk?
A typical Frontleap deployment runs approximately one to three months. The process starts by connecting the relevant enterprise systems and modelling the workflows, terminology and rules used by the order desk. Frontleap can then be introduced with one team, location or workflow before expanding more broadly. The objective is to prove the workflow against the customer’s own operating baseline rather than require a large transformation program before the order desk can start using the product.
Does clean core mean removing every customization?
No. It means keeping the ERP standard and moving business-specific logic out of the core. Some specific belongs in the system of record. Much of it, like product equivalences, customer habits and pricing exceptions, can live in a layer above it, where it changes without touching SAP.
What happens to spreadsheets and workarounds during an S/4HANA migration?
Custom screens and fields are scoped and priced. Spreadsheets and detours around controls are usually not counted at all, so the knowledge they carry is neither migrated nor replaced. Inventory them before the scope is frozen.
How can you keep business-specific logic without customizing SAP?
Put it in a layer that runs alongside the ERP. The ERP stays the system of record. The layer carries the rules, context and exceptions of the work, and survives upgrades because it was never inside the core.
Why do counter staff ignore the memos and pop-ups in the ERP?
Usually not because the information is wrong, but because it is delivered in a way that blocks the sale in progress. Staff learn to dismiss it to keep serving the customer. The fix is to deliver the same information without interrupting the action, so both administration and sales get what they need.
What is the difference between training staff on the ERP and making them autonomous?
Training teaches the screens. Autonomy comes from having the answer at the moment of the sale: which product the customer means, which branch has it, what to do when the standard path doesn't fit. A workspace that follows the real sequence of the counter, and shows those answers in the flow, lets new hires serve the customer without calling a senior colleague.
Can you improve counter work without customizing SAP?
Yes. The specific way your counter works can live in a layer above the ERP instead of inside it. SAP stays the system of record, and the workspace carries the sequence, the context and the shortcuts your people need (why that matters before a migration).
How do you reduce the order desk’s dependence on a few senior people?
Capture what they know while the work happens, not in a manual. Follow them through one real workflow and note every time they leave the system. Record each rule they apply with its source, scope and owner. The knowledge then stays with the business when people move on, and new hires can draw on it from day one.
How do you keep order knowledge current when catalogues, prices and teams change?
Give every rule an owner. When someone corrects an order, the owner decides whether the correction becomes shared knowledge, where it applies, and which old instruction it retires. A correction on one order should never silently change every future order.
What should an AI agent handle alone, and what should stay with a person?
An agent can act where an approved rule fully determines the next step. Judgment, negotiation and commitments beyond its authority go to the right person, with the context attached. Write down what proceeds, what pauses and what allows the work to resume before anything is delegated.
Does clean core mean removing every customization?
No. It means keeping the ERP standard and moving business-specific logic out of the core. Some specific belongs in the system of record. Much of it, like product equivalences, customer habits and pricing exceptions, can live in a layer above it, where it changes without touching SAP.
What happens to spreadsheets and workarounds during an S/4HANA migration?
Custom screens and fields are scoped and priced. Spreadsheets and detours around controls are usually not counted at all, so the knowledge they carry is neither migrated nor replaced. Inventory them before the scope is frozen.
How can you keep business-specific logic without customizing SAP?
Put it in a layer that runs alongside the ERP. The ERP stays the system of record. The layer carries the rules, context and exceptions of the work, and survives upgrades because it was never inside the core.
Why do counter staff ignore the memos and pop-ups in the ERP?
Usually not because the information is wrong, but because it is delivered in a way that blocks the sale in progress. Staff learn to dismiss it to keep serving the customer. The fix is to deliver the same information without interrupting the action, so both administration and sales get what they need.
What is the difference between training staff on the ERP and making them autonomous?
Training teaches the screens. Autonomy comes from having the answer at the moment of the sale: which product the customer means, which branch has it, what to do when the standard path doesn't fit. A workspace that follows the real sequence of the counter, and shows those answers in the flow, lets new hires serve the customer without calling a senior colleague.
Can you improve counter work without customizing SAP?
Yes. The specific way your counter works can live in a layer above the ERP instead of inside it. SAP stays the system of record, and the workspace carries the sequence, the context and the shortcuts your people need (why that matters before a migration).
How do you reduce the order desk’s dependence on a few senior people?
Capture what they know while the work happens, not in a manual. Follow them through one real workflow and note every time they leave the system. Record each rule they apply with its source, scope and owner. The knowledge then stays with the business when people move on, and new hires can draw on it from day one.
How do you keep order knowledge current when catalogues, prices and teams change?
Give every rule an owner. When someone corrects an order, the owner decides whether the correction becomes shared knowledge, where it applies, and which old instruction it retires. A correction on one order should never silently change every future order.
What should an AI agent handle alone, and what should stay with a person?
An agent can act where an approved rule fully determines the next step. Judgment, negotiation and commitments beyond its authority go to the right person, with the context attached. Write down what proceeds, what pauses and what allows the work to resume before anything is delegated.
What is AI order entry for SAP?
AI order entry for SAP uses artificial intelligence to interpret customer requests, match them to catalogue items and prepare sales orders using relevant business information, such as pricing, inventory, customer records and order history. SAP remains the system of record.
Does AI order entry replace the customer service representative?
No. AI-assisted preparation can identify a likely product, bring pricing and customer information into view, surface a shortage and prepare the order for review. The representative resolves ambiguity, agrees on delivery or substitutions, and confirms that the order reflects the customer’s agreement. Commercial exceptions go to someone with that authority.
How is Frontleap different from SAP’s Order Management Assistant?
SAP describes its Order Management Assistant as orchestrating Joule Agents or custom agents for order fulfilment risks, sourcing optimization and revenue reconciliation. Frontleap Order Desk focuses on complex order preparation: a CSR workspace that brings the customer request, product match, stock, price and approval together. The functions overlap in part, so the practical test is how each handles your team’s terminology, customer rules and exceptions.
How should you evaluate an AI order entry solution?
Test it with orders that made your experienced people pause: an old product number, an unclear unit of measure, an expired quote or a request that conflicts with available stock. Check that the representative can see the evidence behind a match, identify missing information, correct the proposal, involve the right authority and verify the final order. Measure preparation time, corrections, unresolved questions and errors found after entry.