The order starts at the counter, not in the ERP.
A contractor walks up to the counter. He doesn't have a product code.
He has a job to finish, a truck outside, and a way of naming things that exists nowhere in the catalog.
He wants to know if you have it, how much, and whether he can leave with it today.
Everything that happens in the next ninety seconds, the order, the availability check, the substitution, the price, is what we mean by operations. And almost none of it happens the way a system diagram says it does.
What actually breaks at the counter
In enterprise systems, the standard path is almost always well covered.
What breaks is the variation, and at a counter, variation is not the exception.
Here's the kind of thing we watched happen.
A perfectly ordinary transaction, the sort a store completes hundreds of times a day, would become impossible to finish because one small thing changed:
the payment method.
Nothing exotic. Nothing anyone would think to write in a specification.
Just a normal customer doing a normal thing slightly differently than the standard case assumed.
That's the pattern, and once you've seen it you see it everywhere:
the system handles the version of the job that was designed, and the floor lives in every other version.
So one of our first working rules came directly out of that: keep simple things simple.
If a task is simple in real life, it has to stay simple on screen, no matter which variation it happens to take that day.
The information nobody reads
The second thing we saw is more subtle, and it's the one that changed how we design.
The system was pushing contextual information at store staff, memos it forced onto the screen. In theory, useful. In practice, nobody read them. Salespeople had learned to dismiss them on reflex, and they were frustrated at having to fight their own tools to keep serving the person in front of them.
Here's the part that matters, and it's why you have to be there to understand it:
the information wasn't wrong, and the administrative team had good reasons to want it seen.
Both sides were right.
The problem was never the content, it was that the content was delivered in a way that blocked the work.
So we designed for both sides at once, and found interface patterns that let information reach the person without interrupting the action.
Administration gets its message through.
Sales keeps moving.
The result was measurable in the simplest way possible: store staff got faster.
How we deployed: one day a week on the store floor
Instead of running requirements workshops, the Frontleap team worked shifts at Canac's counters for months before and during deployment.
We could have booked a room and gathered stakeholders.
Instead, one day a week for months, our team worked the floor,
standing next to the people taking orders.
Not a site visit. Not a workshop. A recurring shift: watching the actual sequence, asking the obvious questions, being corrected.
You learn things in that position that you cannot learn any other way. You see where someone hesitates. You see the workaround they've built and stopped noticing. You see which screen they dismiss without reading, and why they're right to.
We saw it, so we built it
The clearest example of what floor time produces is the inventory view.
We watched how store teams updated stock levels and tried to get a total inventory picture across the network. It was extremely complex, complex enough that, at first, we didn't fully understand it ourselves. That was the signal. When a task is that hard to explain to an outsider, it's usually costing far more than anyone realizes.
So we built the opposite of what we saw:
plant inventory and network-wide inventory brought together in a single click.
It's now one of the features our users mention most.
What we built: an operational workspace that matches the work
A Frontleap workspace follows the real sequence of a job rather than the structure of the underlying ERP.
None of this is a new system to learn. It's an operational workspace shaped by the real flow of a real counter: simple things stay simple, information arrives without blocking the action,
and the answer to "do we have it?" is one click away instead of a small research project.
SAP stays exactly where it should be, the system of record.
The workspace is where the work gets done.
The difference isn't that the software is prettier. It's that it was designed on real days, with real customers waiting.
That's not something you can specify.
You have to go see it.
How this changes the customer experience
The operational chain is direct: a workspace built from the real work produces an employee who can act, which produces a customer who gets served properly.
A customer never cares which ERP you run. They care whether the person in front of them can answer with confidence, complete the order without a detour, and do it without disappearing into a back office.
That's the whole chain: a workspace built from the real work → an employee who can act → a customer who gets served properly.
We judge everything we build on that last link.
How Frontleap deploys: engineers inside your operations
Frontleap uses a forward-deployed model: engineers work inside the customer's operations through rollout, rather than delivering software and handing it off.
Working the floor wasn't how we started, it's how we work.
Our engineers deploy inside your operations, alongside your teams, and stay through the rollout.
Not to hand over software and leave, but to make sure what we built actually changes the day.
That's also why adoption isn't something we hope for after go-live.
It's what we're building from the first shift.
The ERP records the work. We make sure it gets done.
Frontleap is an operational execution layer that runs on top of SAP.
It is deployed at Canac — Québec's largest independent hardware and building-materials chain, and a 6,000-employee SAP enterprise — for order processing and inventory decisions at the counter. The deployment won an OCTAS 2026 award. Frontleap does not replace the ERP: SAP remains the system of record, and Frontleap is where the work gets executed.
Authors
Frequently asked questions
What is Frontleap, exactly?
Frontleap is the execution layer that runs alongside your ERP. 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.