An implementation lasts a few months. Support lasts for as long as you run the system, which for most businesses is somewhere between five and fifteen years. Yet support is routinely chosen by taking whatever the implementing partner offers, at whatever price appears on the second page of the proposal.
Here is what we would look at, including the situations where the right answer is a bigger firm than us.
What good support actually has to cover
Most support propositions are described in terms of response times, which is the least interesting part. A useful arrangement covers five distinct things, and it is worth checking each explicitly:
- Day-to-day questions and errors — the visible part, and the one every provider quotes for.
- Small changes: report layouts, formatted searches, approval thresholds, new users and authorisations. Whether these count as support or as chargeable projects makes an enormous difference to how the relationship feels.
- System health: query performance, database growth, failing integrations and recurring errors, ideally spotted before they become incidents.
- Version upgrades, including working out what your customisations will do beforehand.
- Knowledge: somebody maintaining an understanding of why your system is configured the way it is.
The fifth is the one that determines whether the other four work. Support fails far more often through ignorance of your configuration than through slow response.
The questions worth asking
“Who specifically will be answering our tickets?”
Listen for whether the answer contains names or a description of a pool. Neither is automatically wrong — a pool with good internal documentation can work, and a single named consultant is a continuity risk if they leave. What you want to hear is a concrete answer to how knowledge of your system is retained, rather than a reassurance that everybody has access to the notes.
“What happens in the first month, before support starts?”
A provider taking on a system somebody else built should want to examine it first: configuration, customisations, integrations and data. If they are willing to start supporting a system they have never looked at, they are either going to learn it at your expense or guess. Both are worse than a short paid review up front.
“Which of these is included and which is chargeable?”
Take a real list into the conversation. A new Crystal Reports layout. An approval threshold change. A new user with a copied permission set. A formatted search. A month-end posting that failed. An integration that stopped overnight. A version upgrade. Get each answered, and get it in writing. This is where most support relationships turn sour, and it is entirely preventable at the point of signing.
“How do you handle a problem that keeps recurring?”
A good answer distinguishes between fixing the instance and fixing the cause, and describes a route to getting the cause addressed. A provider whose model is volume of tickets closed has no incentive to reduce the number of tickets you raise. Ask directly what their ticket volume looks like across their client base over time.
“What do we get if we leave?”
Ask before you sign, not when you are leaving. You should own your configuration documentation, your customisation register, the source and deployment packages for anything bespoke they built, and any reports written for you. If the answer is vague, the arrangement includes a lock-in that has nothing to do with quality of service.
“How do you approach upgrades?”
The reason most businesses sit on old versions is uncertainty about what will break. A partner should be able to describe assessing the impact on your customisations, upgrading a test environment first, running regression tests against it, and a live release with a rollback position. If upgrades are described as a large annual project with an air of dread, that is what they will be.
The most revealing question
Ask what they would tell you not to do. A partner who has never talked a client out of a customisation, or recommended against work they could have billed, is either very new or is not exercising judgement on your behalf. The answer should be specific and recent.
Warning signs
- Willingness to support a system without reviewing it first.
- Response times quoted as a single number rather than graded by business impact. A failed month-end posting and a report layout request are not the same problem, and treating them identically serves nobody.
- Reluctance to put the included-versus-chargeable boundary in writing.
- A multi-year minimum term. A provider that needs a long contract to retain clients has the incentives the wrong way round.
- Bespoke work built directly into the database rather than through supported interfaces. Ask specifically whether they use triggers or direct table updates on SAP tables. This is the usual reason businesses find themselves stranded on an old version.
- No mention of documentation anywhere in the proposal.
- Pricing per ticket. It puts you and your provider on opposite sides of every question.
When a larger partner is the better answer
We are a small consultancy, and there are circumstances in which we are not the right choice. It is worth being clear about them, because choosing a specialist firm when you needed scale is an expensive mistake:
- You need genuine out-of-hours or weekend cover. A small team cannot staff a rota around the clock without it being a fiction.
- You operate across several countries and need local-language support or in-country presence.
- Your procurement process requires a supplier of a certain size, or contractual terms that only a larger business can carry.
- You need several consultants available simultaneously at short notice, or on site for extended periods.
- You require a formal, contractually guaranteed service level with financial penalties attached.
If two or more of those apply, look at larger partners. You will trade some depth of familiarity with your system for capacity and coverage, and in those circumstances that is the right trade.
Before you sign
A short checklist:
- The included-versus-chargeable boundary is written down, with examples.
- Response times are graded by business impact, and the grades are defined.
- There is a named escalation route with a name attached.
- The onboarding review is scoped and priced, and its output belongs to you.
- Exit terms specify what you receive: documentation, customisation register, source and deployment packages.
- Upgrade approach is described, including who tests the customisations.
- The notice period is one you would be comfortable with if the relationship went badly.
If you are currently unhappy
Before moving, work out which of three things is actually wrong, because they have different answers. The provider may be poor. The configuration may be poor, in which case a new provider inherits the same problems and you will be disappointed twice. Or the arrangement may be mismatched — you are buying reactive support when what you need is somebody improving the system.
A review by a third party will tell you which, and it is worth the few days it takes. Moving provider is disruptive, and doing it for the wrong reason means doing it again.
Want a second opinion on your current arrangement?
Tell us what keeps going wrong. We will give you an honest read on whether the problem is the provider, the configuration, or something that needs fixing properly once — and we will say if we think your existing partner is doing a reasonable job.
Where to go next
- SAP Business One Support — How our own support works, judged against the criteria in this article.
- Development & Add-ons — What to do about customisations you inherited and nobody can explain.
- SAP Business One — Implementation, support and development across SQL Server and SAP HANA.