Most CPQ projects don't fail because of the technology.
That's the first thing Stephen Metts will tell you, and after 12+ CPQ go-lives, he's earned the right to say it. As Zaelab's VP of Solutions and Innovation, Stephen has seen what actually breaks during CPQ implementations, and more importantly, what it takes to get them right.
LogiKit™ came out of that experience. Not from a whiteboard session or a product roadmap exercise, but from watching the same failure patterns repeat across engagements and deciding to do something about it.
I sat down with Stephen to talk about what drove us to build it, what it actually is, and why CPQ modernization is becoming a defining question for enterprise revenue teams right now.
Let's start at the beginning. After 12+ CPQ go-lives, what's the one pattern you kept seeing across failed or stalled implementations?
"The same one, almost every time: technology wasn't the problem. The process underneath it was. Companies would buy a modern CPQ engine and then spend months bending it to fit a quoting process that was already broken — manual approvals, pricing rules living in someone's head, exceptions handled over email. CPQ didn't fix that. It automated the dysfunction and made it faster to produce the wrong quote."
That framing matters. The question we hear most from revenue operations and IT leaders is "why did our CPQ project stall?" The answer is almost never the platform. It's the process the platform was asked to run.
Stephen also named a second pattern: the blank-canvas problem. Every implementation started from zero. The same configuration rules, the same approval patterns, the same pricing logic, rebuilt from scratch for each client as if no one had ever done it before.
"When you map a client's process visually for the first time and they say 'that's exactly what's broken and nobody has ever drawn it before,' you realize how much of the pain was just never made visible."
Where does time actually go in a CPQ deployment?
This is one of the most underestimated problems in CPQ. Before LogiKit, a real deployment could run for many months, and the platform itself was rarely the bottleneck.
"The time goes into discovery, rule-building, and rework," Stephen explains.
"You spend weeks just extracting how the business actually prices and approves things, because most of it isn't written down anywhere — it lives in transcripts and conversations, described four different ways across four different sessions."
The middle phase is where projects stall: after the tool is configured but before sales trusts the quote. Teams rebuild standard logic by hand, then lose another cycle on validation. Nobody's confident the rules hold up across the full range of deal scenarios.
This maps directly to what we hear from revenue leaders in the market. Across our recent conversations with commercial and operations teams, the most common pain points aren't technical — they're process failures that slip through the cracks between CRM and quoting, between quoting and fulfillment. Quotes that can't be built as submitted. Friction moving deals from CRM into ERP. Customer data is scattered across systems. Pricing that doesn't reflect actual costs.
The clock is eaten by reinventing things that didn't need to be reinvented.
How often is "broken process" actually the root cause when CPQ goes sideways?
"It's the root cause more often than anyone wants to admit. When a CPQ implementation goes sideways, the post-mortem usually blames the platform or the integrator. But if you trace it back, the real failure was lifting a broken manual process and pouring concrete around it."
New technology exposes a broken process. It doesn't repair it. If your approval chain has discretionary steps with no clear pricing authority, automating it just gives you a faster way to route a deal into a bottleneck.
The implementations that succeed are the ones where someone had the discipline to redesign the process as part of the build, not preserve it out of habit. And making that happen requires making the friction visible and undeniable — putting the client's own handoffs and delays in front of them as something quantified, not just described.
Why We Built LogiKit™
Stephen's answer is straightforward: LogiKit is a head start.
"It's an accelerator that brings the standard, recurring portion of a CPQ implementation pre-built — the configuration rules, pricing patterns, persona and pain-point libraries, and industry blueprints that show up on nearly every engagement — so your team spends its time on what's actually unique about your business instead of rebuilding the foundation everyone rebuilds."
For a VP of Sales Ops, that means shorter time-to-value and a de-risked build. You're not starting at a blank configurator. You start from proven patterns, layer in what's specific to your business, and your people configure with confidence instead of guessing.
For a Head of IT or a CRM architect, the more important dimension is architecture. LogiKit is built composable and API-first. It modernizes your quoting without welding you to a single platform's UI. It's the difference between a project that starts at zero and one that starts well down the road — with a revenue engine that connects CPQ, CRM, and the rest of the commercial stack.
Where did the 300+ pre-built solutions actually come from?
This is the question Stephen gets most often, and his answer is blunt.
"They came out of the work. None of it was designed in a conference room as a theoretical best-practice catalog. Every rule and blueprint earned its place because it solved a real problem on a real engagement — and then it kept showing up."
After enough go-lives, you stop seeing one-off requirements and start seeing the same shapes over and over: the same pain points, the same persona behaviors, the same pricing and approval patterns.
They emerged. Then Zaelab hardened them: took the patterns that recurred across implementations, generalized them so they weren't tied to one client's quirks, and packaged them as reusable blueprints and libraries. That's why they hold up. They're not somebody's idea of how CPQ should work. They're the distilled version of how it actually worked, repeatedly, in the field.
A lot of companies still run CPQ tightly coupled to their CRM or ERP. What breaks when you try to modernize from that architecture?
"Everything that touches the seams breaks. When CPQ is tightly coupled to the CRM or ERP, the pricing and configuration logic ends up entangled with that platform's data model and UI lifecycle. So when you try to modernize, you're not migrating a quoting engine — you're untangling years of customizations that assumed the old foundation would never move."
This is one of the central reasons Zaelab made a deliberate architectural choice to build on a headless, API-first CPQ foundation. Coupling is where modernization goes to die. If your quoting logic is fused to a specific CRM or ERP UI, every change becomes a platform project.
A headless, API-first core means the configuration and pricing engine is a service. It answers questions and returns answers. The experience layer sits on top of it rather than trapping it. That's what makes the 8-layer CPQ architecture possible — each layer can evolve independently, without the whole system becoming a renovation project every time the business changes.
Stephen is direct about the tradeoff: you take on more architectural responsibility up front. You have to think deliberately about the experience layer and about integration. But the alternative buys you a fast demo and then a multi-year renovation the first time the business changes.
"I'd rather pay the design cost early and stay composable than save a few weeks and lose the optionality."
For industries like manufacturing and telco, this isn't a preference — it's a necessity. Highly complex product configurations, pricing that varies by region, contract, and volume, and long regulated sales cycles all demand an architecture that keeps up with change rather than quietly becoming what holds the business back.
For a company that's tried CPQ before and had it fail, what's different about the LogiKit approach?
"The second attempt doesn't start from zero, and it doesn't repeat the bet that failed the first time. Most failed CPQ projects failed for one of two reasons: they automated a broken process, or they tried to build everything from scratch and ran out of runway. LogiKit attacks both."
The library means you're not rebuilding the foundation. Starting from proven patterns forces a conversation about how the process should work rather than blindly preserving the old one.
The other difference is confidence at the rule level. A lot of first attempts collapse during validation — go-live slips because nobody trusts the quotes. With validation that exercises scenarios in bulk, the team can see the logic holding up before launch instead of discovering problems live.
That's a fundamentally different risk profile than "blank canvas, manual testing, fingers crossed."
The ServiceNow SKO recap from earlier this year shows how this plays out in practice. When CPQ is positioned as the starting point for a connected revenue engine, the conversation with sales teams shifts. They're not asking whether the quotes will be right. They're asking how fast they can get there.
CPQ modernization is a term we're hearing more. What's actually driving it right now?
Stephen sees several forces converging at once.
There's a technology cycle: headless, API-first, composable architecture finally made it practical to modernize quoting without ripping out the CRM or ERP underneath. There's a generational shift in buyers who expect a B2B experience that feels like the consumer web, not a PDF and a multi-day wait. And there's the simple fact that CPQ deployed years ago is now technical debt that can't keep pace with how fast the business changes.
There's also a clear external signal: the major platforms are converging on agentic commerce, with new transaction-layer standards and CPQ being reframed as quote-to-fulfillment at scale.
"When the ecosystem starts treating quoting as part of an automated, agent-mediated flow, the old tightly coupled, manually maintained system stops being viable. That's what 'CPQ modernization' really names: the point where staying put became more expensive and riskier than modernizing."
There's also a human dimension that gets underestimated: the demographic time bomb. In many companies, the real pricing and configuration logic doesn't live in a system. It lives in the heads of a few senior people who've been there for years. When they retire, that knowledge walks out the door.
LogiKit addresses this directly. The act of building on blueprints and explicit configuration rules, and capturing the pain points, personas, and pricing logic surfaced in discovery, means that knowledge has to be written down, structured, and validated. The institutional knowledge becomes durable and maintainable by the next team. You're converting tribal knowledge into systematized knowledge before the people who hold it leave, instead of trying to reconstruct it afterward.
Where do you see CPQ implementation going in the next two to three years?
"Two things will look different. First, deployment timelines collapse — the blank-canvas, build-it-all-from-scratch implementation becomes the exception, not the norm. Second, the experience layer separates from the engine for good. Composable, API-first architecture becomes the assumption rather than the brave choice."
The bigger shift is agentic. Agents handling the preparation work: quote assembly, validation, scenario testing. Humans owning the decisions that matter.
Stephen is deliberate about the framing: quote acceleration, not autonomous quoting. The agent does the preparation. The human still owns the commit. That distinction matters — and it's where the differentiation lives as the major platforms race toward agentic commerce.
Over the next two to three years, that's where this goes. Faster, more automated assembly and validation. Clear human ownership of configuration and pricing decisions. Maintenance that gets lighter because systematized, validated logic is far easier to evolve than the brittle, hand-built systems most teams are living with today.
Why It Matters
If you're evaluating CPQ, in the middle of a stalled implementation, or thinking about what a connected revenue engine actually looks like, the honest answer is: the technology has never been the hard part.
The hard part is the process underneath it. The institutional knowledge that lives in people's heads. The approval chains nobody mapped. The pricing logic described four different ways in four different sessions. The gap between "we configured the tool" and "sales trusts the quote."
LogiKit was built because those problems are solvable, and because the patterns for solving them were already there, earned across over a dozen real go-lives. The point isn't a cleverer CPQ. It's getting good teams to a trusted quote without making them reinvent the foundation every single time.
That's what we built. And increasingly, it's what the market is asking for.
Interested in what a LogiKit-powered CPQ implementation looks like for your business? Explore our CPQ solutions or read more about how CPQ is becoming the revenue engine of modern B2B.
You can also read Stephen's deep dive on CPQ architecture and the 8 layers of configuration excellence, or learn about how we compare ServiceNow CPQ vs. Salesforce CPQ for complex B2B environments.
