Swiftly Business ConsultingSelect language
Post-go-live support rarely fails for technical reasons. It fails because support was scoped as a phase, the knowledge left with the implementation partner, and nothing turns a recurring incident into a fixed process.
The project closes on time. The steering committee gets its final green slide and the implementation partner is thanked in an all-hands email. Six weeks later, finance is keeping a shadow spreadsheet for the month-end close, two people in the warehouse have gone back to phoning the office, and nobody has logged into the customer portal you paid to configure. Nothing is broken. The system is up, the integrations are running, the uptime report is clean. The organisation is simply running worse than it did in the last month of the project.
When this happens the instinct is to look at the software. It is almost never the software. The biggest threat to an ERP or CRM go-live is organisational: who owns the process once the project team disbands, where the knowledge lives, and what happens to a problem the third time it appears. Systems fail loudly and get fixed. Organisations fail quietly and get worked around — and a workaround, unlike an outage, never triggers an alert. Below are the six patterns we see most often in Belgian and Dutch mid-market companies, and a short list of warning signs you can check against your own.
Implementation contracts almost always include hypercare: a period of elevated attention after go-live, typically measured in weeks rather than months. It is useful, and it is not support. It is the tail end of a project, staffed by project people, priced inside the project budget. When it ends, what replaces it is usually described as business as usual — a phrase that in practice means nobody has decided anything. The demand does not stop at the end of hypercare; it changes shape. The first weeks are dominated by people who cannot find a button. Months two to six produce the questions that actually cost money: the close that no longer reconciles, the pricing rule that behaves differently for one customer group, the intercompany flow nobody tested because the acquisition completed late. Those need someone who understands the business, and they arrive precisely when the people who understood it have been released.
During an implementation a small group accumulates an enormous amount of undocumented knowledge. Why the credit-limit check sits before order confirmation rather than after it. Which customer master fields the logistics interface actually depends on, as opposed to the ones the specification says it depends on. Why the Dutch entity carries an exception in its tax determination. Almost none of this is written down, because for the duration of the project everyone who needs it is in the same room. At handover the deliverables are documents: configuration workbooks, test scripts, training decks, an authorisations matrix. They describe what the system does. The expensive knowledge is why it does it that way, and why is not on the deliverables list. When the partner demobilises, that knowledge leaves the building, and unlike a missing document you cannot notice its absence until the day you need it.
Support is often bought as a service desk: priced per user or per ticket, staffed by people trained on the software’s generic behaviour rather than on your configuration of it. Within its scope that team is competent. Access problems, licences, printing, a report that returns nothing, a user who needs a role added — all handled, and handled quickly. Then a ticket arrives saying that since Tuesday, orders for one customer group are picking up the wrong delivery terms. That is not a software question. It is a question about a pricing condition, a customer master change and a shipping rule interacting inside your order-to-cash process, and answering it properly requires someone who knows how that process is supposed to run. A generic desk will route it, escalate it, and eventually close it with a manual correction. The manual correction then becomes the process, which nobody records as a failure because the ticket was closed inside its service level.
Nearly every organisation names a system owner after go-live, usually in IT. Their remit is availability, upgrades, authorisations, integrations and cost. All of it necessary, none of it covering whether order-to-cash or procure-to-pay actually works end to end. Business processes cross departments; system ownership does not. When the fault sits between sales and logistics — which is where it usually sits — there is no one whose job it is to arbitrate, so each department builds a local fix and the gap between them widens. In a Benelux company of 200 people this is sharper than in a group of 5,000, because there is no process office to fall back on and no spare capacity to invent one. Ownership defaults to whichever key user complains most persistently, on top of the job they were already doing. That is not a governance model, and it does not survive that person taking a new role.
Support contracts are measured on response time and resolution time. Both are easy to count, both are easy to report, and neither tells you whether the same failure will be back next month. A queue optimised for closure speed will reliably prefer the workaround to the fix, because the workaround takes twenty minutes and closes the ticket while the fix takes a process discussion, a test cycle and a change window. The number that would tell you something is what share of this month’s tickets are recurrences of something already seen. Few organisations measure it, because doing so means categorising tickets by the business process they touch rather than the module they were logged against. The ones that start measuring it are usually uncomfortable with the answer: a small number of underlying process defects generating a disproportionate share of the volume, quietly, for years.
Every recurring incident is a process defect wearing a ticket number.
This is the failure that contains the other five. Even where the knowledge survives and someone owns the process, most organisations have no mechanism that converts this keeps happening into a change that gets made. Incidents live in a service desk tool. Changes live in a project pipeline that only opens when there is a budget round. Between the two sits a gap, and recurring problems fall into it permanently. The route out does not need to be sophisticated — it needs to be short and boring. A monthly review of repeat incidents grouped by process. One named person with the authority to declare something a process defect rather than a user error. And a standing budget for fixes too small to be projects, because without a budget line every improvement has to be justified as though it were a new initiative, and none of them ever clear that bar.
None of these on its own proves your support is failing. Three or four together usually do.
It is not more hours, and it is rarely a bigger service desk. It is a small number of structural things. A named process owner on the business side for each end-to-end flow, with the authority to decide between departments. Support staffed by people who have read your process, not only the vendor’s manual. A decision log inherited from the implementation and kept alive as configuration changes. Recurrence measured alongside resolution time. And a standing route from repeated incident to permanent fix, with a modest budget attached to it so that small improvements do not have to compete with capital projects.
That capability can be built internally or bought in, and for most Benelux mid-market companies it ends up as some of each: internal ownership of the process, external hands for configuration, development and the awkward integration work. What does not work is buying it as an afterthought, at a price set by ticket volume, from whoever is cheapest once the project budget has been spent. The best moment to design post-go-live support is before go-live, while you still have leverage with your partner and the knowledge is still in the room. The second-best moment is now — by reading back through the warning signs and being honest about how many of them you recognise.
KEEP READING
Post-go-live support costs what it costs whether you budgeted for it or not. Seven places the money actually goes when support is under-resourced — and what a properly funded arrangement looks like instead.
Go-live is the day your new system becomes the system of record — not the day the project ends. What the weeks after it actually consist of, who owns each part, and when hypercare should stop.
Go-live is the most heavily defended date in an ERP project and the least meaningful one. Governance treats it as an ending — which is why the outcome the system was bought to produce never gets measured.
Book a free 30-minute call. We will go through your current support arrangement, your recurring incidents and who actually owns each process — and tell you plainly where the gaps are.
Currently accepting new engagements for Q2 2026.