An enquiry arrives on Tuesday morning, in a shared mailbox. Somebody copies it into the CRM as an opportunity and sends the technical part to whoever reads drawings. That person builds the configuration in a separate tool. Pricing comes off a spreadsheet that one person maintains. The quote goes out as a PDF from somebody's laptop. On Thursday the customer asks for a version with a different frame size and a longer warranty. By the following Tuesday three people hold three different ideas of what was offered, at what discount, and who agreed to it.
Nobody in that story made a mistake. The sale crossed a seam between systems four times, and each crossing was a person retyping something that had already been decided correctly once.
We are the.good.code;, a founder-led team that builds custom software, CPQ (configure, price, quote) and configurator systems, and ERP-integrated operational layers for manufacturers. We spend our working weeks inside this seam. Our view is that most lost deals in configurable-product businesses are lost in the days the buyer spent waiting while the seller worked out which version of the offer was current, and price gets the blame afterwards.
This article is about the handoff itself. CRM and quoting integration for manufacturers usually gets discussed as a choice between platforms, and our row-by-row comparison of Open Mercato and Salesforce covers that ground. Here we stay inside the join: what leaks when a quote crosses it, and what one audit trail from enquiry to paid invoice needs before a platform is even on the table.
Why does one sale end up in three systems?
Because the systems were bought at different times by different departments, and nobody ever owned the join.
The pattern shows up in official statistics. In the EU, 46.45% of enterprises used ERP software in 2025 and 28.51% used CRM software, according to Eurostat's survey on ICT usage and e-commerce in enterprises, covering enterprises with at least 10 employees, with figures extracted in May 2026. The gap widens with size: 89% of large enterprises ran ERP against 65% running CRM. That is a description of the sales floor before it is a technology adoption curve. A large manufacturer is more likely to own a system that can raise an invoice than one that holds the customer conversation. The conversation then lives in mailboxes and spreadsheets.
Configuration adds a third layer. In an IDC InfoBrief sponsored by Configit (doc #US51047923, September 2023), based on a survey of 511 discrete manufacturing companies in North America and Europe, manufacturers reported using around three different configuration tools on average, and 33% named connecting product design and engineering with sales and service as a top goal for the coming year. Configit sells configuration software, so treat that as a vendor's own research rather than an independent market benchmark. The shape of it matches what we walk into: one product family configured in a tool bought in 2019, another in a spreadsheet, a third in the head of the engineer who has been there longest.
What gets lost when a quote crosses the seam?
Four things, and each one costs money in a different way.
- The current version of the quote — the offer lives as a file, so the newest copy wins by accident. Cost: delivery against a superseded specification.
- The agreed discount and its author — approval happens in a call or a chat message. Cost: nobody can say whether a customer's price is policy or a favour.
- The specification change from the last call — the change has to reach four places by hand. Cost: rework in engineering, or a promise the factory cannot build.
- The reason the deal ended — loss reasons sit in the CRM, the offer sits elsewhere. Cost: loss analysis with no offer attached to the decision.
The current version. When a quote exists as a document instead of a record with a history, the newest file wins by accident. We have watched a company deliver against v3 while finance invoiced against v2, because v3 was attached to a reply that never made it out of one inbox.
The agreed discount and who agreed it. In most of the businesses we work with, discount approval happens verbally or in a chat message. The number reaches the quote. The authority behind it stays outside every system, so a year later nobody can answer whether that customer's price is a policy or a favour.
The specification change from the last call. This is the expensive one. A change agreed with the customer on Thursday has to reach the configurator, the price, the delivery promise and eventually the bill of materials. Any of those four can miss it.
The reason the deal ended. Loss reasons live in the CRM if they live anywhere. When quoting happens outside it, the record of what was offered sits somewhere else, so the loss analysis holds a decision with no offer attached to it.
What does the seam cost?
Waiting time, and the buyer is the one who measures it. Quote turnaround time is where the cost surfaces, because it is the only part of the seam a customer can see.
Research on response speed is thinner than the sales industry pretends, and most of the numbers circulating are untraceable. One primary study holds up. In 2007, Dr James Oldroyd, then a Faculty Fellow at MIT Sloan, analysed three years of data from six companies, covering over fifteen thousand web-generated leads and over one hundred thousand call attempts, and found that the odds of contacting a lead called after five minutes versus thirty minutes drop by a factor of one hundred. That study is nearly twenty years old, it covers web leads and phone calls rather than industrial RFQs, and the data came from a vendor's own dialling system. It is still the cleanest measured evidence we could find that buyer attention decays steeply in the first hours, and every hour spent reconciling versions is an hour spent inside that decay.
Peer-reviewed work on engineer-to-order manufacturing points at the same mechanism from the operations side. In a four-case study published in Production Planning & Control, Shurrab, Jonsson and Johansson found that formalised task instructions and supportive information systems acted as integrative coordination mechanisms across the customer order fulfilment process, and that formalisation "minimises confusion and increases consistency across enquiries, which minimises reworks and delays". The finding is qualitative. It says the seam is a management object, and that the companies handling it deliberately spend less time redoing work.
Is this an integration problem?
Partly. Integration removes the retyping. Ownership of the seam is a separate decision, and it is the one that gets skipped.
We built the integration layer between Elfsquad and Windchill for Dewulf, an agricultural machinery manufacturer building more than a thousand configurable machines a year. Before that layer existed, engineers re-entered the sales configuration into the PLM system by hand, hundreds of engineering hours a year, with the error rate that manual re-entry always carries. Removing the manual step was worth doing on its own terms, and it did not require replacing either system.
Before that work starts, it pays to map your software ecosystem before any integration project, because the seam usually turns out to have more than two sides. What integration alone will not tell you is which system holds the truth when the two disagree. That question has to be answered by a person before it can be answered by code. In our discovery work the answer is usually uncomfortable: the truth lives in a mailbox, and both systems are downstream copies.
The hardest part of closing a seam is rarely the software. It is the spreadsheet, and the person who maintains it. That file is often the only written record of last year's exceptions, the customer who gets a few extra points of discount because of a conversation in 2022, and the option combination the factory quietly refuses to build. Moving pricing into a system means writing those rules down for the first time, and somebody has to be given the authority to do it.
What does one audit trail from enquiry to paid invoice require?
Six things, in our experience, and none of them require a platform migration to start.
- One record per sale, from first enquiry to settled invoice. A record rather than a document: something with a state, so that "quote sent", "revision requested", "accepted" and "invoiced" are transitions somebody can query later.
- Versions as first-class objects. Every revision keeps its predecessor, with the author, the timestamp and what changed. Version control on quotes is the single cheapest defence against delivering the wrong specification.
- Approvals inside the record. The discount, the payment terms and the delivery promise carry the name of the person who authorised them, in the same place as the numbers they authorised.
- Many hands on one quote. In configurable businesses a quote is rarely one person's work. The technician reading drawings adds the technical content, someone in sales owns the commercial part, someone else sends it. That is a permissions problem on a shared record, and the permission architecture that decides who can change what disappears the moment the quote becomes an emailed file.
- The configurator invoked and left where it is. If a mature rules engine already produces valid configurations, the operational layer should call it and store the result against the deal. Rebuilding working product logic is the most expensive way to fix a handoff.
- The invoice pointing back at the accepted version. Finance should be able to answer "which quote version is this invoice for" without asking sales.
Start with one product line. If a company runs several configurators across several families, we pick the family with the worst pain or the clearest upside and digitise that flow only. A programme that tries to cover everything at once is how these projects acquire a two-year timeline and lose their sponsor.
We have also finished first conversations by recommending no software at all. Some companies arrive with a version-control problem they can solve with a naming convention and one hour of agreement across three people. Selling them a project would be easy and it would delay the fix by a quarter.
Where does Open Mercato fit, and where does it stop?
Open Mercato is an open-source, AI-native framework for building business applications, published under MIT, and its vendor lists us as a certified agency. It matters here because the span from quote to paid invoice, the part of quote-to-cash that sales and finance argue about, sits inside one system in its data model: quotes, orders, invoices, credit memos, payments and tax rules are part of the platform, with the deal pipeline, the stage-transition log and the action log alongside them. If a team exports opportunities into a separate quoting tool today and retypes the result into an ERP afterwards, that is the seam this platform closes.
One boundary belongs next to that promise, because "paid invoice" means different things to a sales director and to a finance controller. Quotes, orders, commercial invoices, credit memos and payment allocation are part of the platform. Statutory accounting and country e-invoicing, such as KSeF in Poland, run in a connected finance system. So a single trail from enquiry to paid invoice covers the commercial documents and the money against them, and the filing layer stays where your accountants already work.
The Catalog & CPQ module is released and in active development. We are deliberate about that sentence. It is not a drop-in replacement for a mature configuration engine with nested rules, 3D visualisation and CAD or BOM output, and we will say so in discovery rather than after the contract is signed. Where the product logic has real engineering constraints, we either extend that module for the client as part of the engagement or we integrate the configurator they already run.
The first of those options is the one we prefer, for a reason worth stating plainly: the client ends up owning the code under an MIT licence. The module we build for one manufacturer's quoting flow stays theirs, and it stays in an ecosystem they can hire someone else to maintain. Buying a proprietary quoting suite gets a company to a working quote faster. It also puts the rules that describe their product inside somebody else's licence.
How do you find your own seam?
Pick one deal that closed in the last quarter and reconstruct it from the systems alone. Find the original enquiry, every quote version, the discount and who approved it, the accepted version, the order, and the invoice. Time how long it takes and note every point where you had to ask a person instead of a system.
Most teams cannot finish that exercise. The gaps it exposes are the specification for the work, and they cost nothing to find.
If it would be useful to run that trace with someone who has done it in configure-to-order businesses before, that is what a welcome coffee with us is: one flow, one hour, and a straight answer on which part of it is a process decision and which part is software. We will also tell you how much of that flow a platform covers and how much has to be built.
Frequently Asked Questions
Do we need a CPQ system and a CRM, or can one system do both?
It depends on how much rule complexity your product carries. A CRM with quoting attached is enough when configuration is a price list with options. A dedicated configuration engine is worth buying when option combinations have engineering constraints, nested dependencies or CAD output. Either way, the decision with the longer shadow is where the deal record lives, because that is the thing that has to survive the handoff. Our read on how the AI-native CRM options compare goes through that choice platform by platform.
What is the fastest improvement if we cannot change systems this year?
Make one place the record of the offer, and give quote revisions version numbers that appear in the file name, the email and the CRM. It costs a naming convention and one hour of agreement, and it removes the most expensive failure in this category, which is delivering against a superseded specification.
How long does it take to get one flow from enquiry to invoice into a single system?
For a single product line with an existing configurator to call, we scope the flow in a workshop and then run a three-week proof of concept covering one real process end to end. Timelines beyond that depend on how many rules have to move and how clean the pricing data is.
Who owns the code if you build this for us?
Open Mercato's core is MIT-licensed, and modules we build for a client belong to that client. The Enterprise Edition is a separate subscription covering audits, security review and priority support rather than the right to run the software.
Sources
- Eurostat, E-business integration, Statistics Explained (data extracted May 2026, reference year 2025) and Larger enterprises used more e-business apps in 2025 (published 20 May 2026)
- IDC InfoBrief, sponsored by Configit, Orchestrating Product Configuration Management: The Secret Weapon of Leading Manufacturers, doc #US51047923, September 2023, n=511 discrete manufacturers in North America and Europe (announcement)
- InsideSales.com / Kellogg / MIT, Lead Response Management study, presented October 2007 (Dr James Oldroyd, MIT Sloan Faculty Fellow; three years of data, six companies, 15,000+ leads, 100,000+ call attempts)
- Shurrab, H., Jonsson, P. and Johansson, M. I. (2022), Managing complexity through integrative tactical planning in engineer-to-order environments: insights from four case studies, Production Planning & Control 33(9-10), 907-924, doi:10.1080/09537287.2020.1837937 (accepted manuscript)
- Open Mercato, orders and quotes guide, taxes, audit logs (project primary)
- the.good.code;, Dewulf: Elfsquad to Windchill integration