You approved a software implementation a year and a half ago. Maybe it was an ERP. Maybe a CRM. Maybe a platform that was going to connect marketing, sales and operations once and for all.
Today, the system technically exists. Someone logs in occasionally. Your team still runs the operation the way it always has — spreadsheets that live on someone's desktop, WhatsApp groups where the real decisions happen, calls between areas to find out where something stands.
The money was spent. The contract was signed. The kickoff had champagne. And nobody uses it.
This isn't a story about your company doing something wrong. It's a story about how most B2B software implementations are structured to fail — and why your skepticism, if you have any, is the most rational reaction you can have.
The standard implementation model works like this: you sign a contract for an amount, with a rough scope, and then the provider starts discovery. They schedule workshops with your teams. They ask questions like "what are your objectives?" and "how does your current process work?" — after you already paid.
That order of operations is the entire problem. The provider is figuring out what to build while billing you for the time it takes to figure it out. Your team is pulled into endless meetings to explain a business they already know how to run. Nobody on the provider's side knows what "good" looks like for your specific operation, so they default to a generic template and try to bend your business around it.
By month six, the scope has drifted. By month twelve, your team has stopped showing up to the workshops because nothing changes between meetings. By month eighteen, the system goes live but it doesn't match how your business actually works. By month twenty-four, everyone quietly returns to the spreadsheets.
If your operations director, your sales lead or your finance manager rolls their eyes when you mention the next implementation, they're not being difficult. They lived through the last one. They remember the meetings that went nowhere, the requirements documents nobody read, the launch where the system asked them to do twice the work they did before.
The resistance you feel internally isn't a culture problem. It's pattern recognition. Your team has seen this movie. The hero dies at the end.
The standard response from providers when you raise these concerns is to add more process: more steering committees, more change management consultants, more user adoption workshops. Each addition makes the project longer, more expensive, and more political — without addressing the structural issue.
The structural issue is that you bought a deliverable that didn't exist yet. You bought a promise to figure it out together. And "figuring it out together" is exactly what consumes two years and produces something nobody uses.
Adding governance to a broken model doesn't fix the model. It just makes the failure more documented.
The order has to be reversed. Before you sign anything for the implementation itself, you should be able to see exactly how your operation will look once it's built — which tools handle what, how information flows between areas, where the financial data lives, how something moves from a signed deal to delivery to invoicing, how a new lead from a form becomes a contact in someone's hands within minutes instead of weeks.
This is not a demo. A demo shows you the software. What you need is a blueprint of your business inside the software: your specific pipelines, your specific handovers, your specific reporting structure. Specific to how you operate, not generic.
If a provider cannot show you that before you commit to the full project, they don't know how it's going to look either. They're going to figure it out on your time and your budget. That's the two-year story repeating.
The blueprint can be paid for separately, and it should take days — not months. That's actually a feature, not a bug. It means the provider has skin in the design, you can evaluate the architecture before committing to the full build, and if it doesn't make sense you walk away having lost the cost of a design — not two years and an implementation budget.
If you're evaluating providers right now, or you know you'll need to in the next twelve months, here is what should be non-negotiable.
First: see the architecture before the implementation. Ask the provider to map out how your operation will function inside the tool — your pipelines, your handovers, your reporting, your financial visibility — and present it to you before any implementation work begins. If they can't or won't, you already have your answer.
Second: clarity on time and effort from your team. A real provider can tell you, in hours, how much of your team's time the project will consume each week and for how many weeks. "It depends" is not an answer. It means they haven't designed the project.
Third: written, specific deliverables per phase. Not "discovery," not "alignment," not "change management." Concrete outputs: this pipeline configured, this process automated, this integration live, this report available. If the contract is full of process language and empty of artifacts, the implementation will be too.
Fourth: a provider that says no. If they agree to everything you ask in the sales conversation, they will agree to everything during implementation too, and you will end up with a system that tries to do everything and works for nothing. A provider that pushes back, explains why something is a bad idea, and proposes an alternative is showing you they have a point of view about what good looks like.
The implementations that don't collapse share a common shape. The design phase is short and produces a concrete blueprint the client approves before the build begins. The build phase is fast — measured in weeks, not quarters — because the thinking happened before the building. The team is trained on a system that matches how they actually work, not on a template they have to adapt to. Within weeks of go-live, people are using it because it makes their day easier, not harder.
This is not a fantasy. It's what happens when the provider treats the design of your operation as the actual product, and the software as the medium for executing it. The software is a commodity. The architecture is the work.
If you're carrying the memory of an implementation that took two years and went nowhere, the lesson isn't to avoid software. The lesson is to demand a different sequence: design first, with full visibility, before you commit to the build. Everything that went wrong last time happened because that sequence was inverted.
If your operation still runs on spreadsheets and WhatsApp, if you've tried to digitalize before without it sticking, and you want to see what an implementation looks like when it's designed before it's built — including how long the blueprint takes, what it costs, and what it actually shows you — this is the model we use. You can see the architecture before you commit to anything. That's the point.