What you should expect from your Business Central support partner

The implementation lasts six months. Support lasts as long as you run the system, which for most businesses is ten years or more. Yet the support contract is the page of the proposal that gets the least attention: a response-time table, a monthly fee, and a signature. This is what you should expect from it, what the good partners do without being asked, and what to look for when yours comes up for renewal.

Start with what support is for

Support is not just "fixing it when it breaks". For a cloud Business Central system that Microsoft updates twice a year, support is four things: keeping the business running day to day; keeping the system current and safe through each release; helping your people use it better; and being the first call when the business changes. A contract that only covers the first is a break-fix contract, and it will leave you stranded on the other three.

Response and resolution: what the numbers should mean

Every contract has a response-time table. Most are meaningless because "response" means an automated email. Insist on these definitions:

• Response means a person has read the ticket, understood it, and told you what happens next. Not an acknowledgement.
• Priority is set by business impact, agreed with you, not by the partner's help desk. "Cannot post sales invoices" is a P1 on the last day of the month whatever the help desk thinks.
• There is a resolution target, or at least a "workaround in place" target, not only a response target. Responding to a P1 in fifteen minutes and fixing it in three days is not a P1 service.
• Reporting. You get the actual numbers every month: tickets raised, by priority, response and resolution achieved against target, the open list with ages. If the partner cannot produce this, they are not measuring it.

As a benchmark for a UK mid-market business: P1 (business stopped) responded to within an hour by a person, worked continuously until there is a workaround; P2 (a department stopped or month-end at risk) within two to four hours; P3 (a user or a process impaired) same or next day; P4 (questions, small changes) within two days. Our own standard is two hours for everything, because we would rather over-serve the P4s than argue about which bucket a ticket is in.

Who answers the phone

The most important question, and the one the contract never states. Is first line a call centre that logs tickets and escalates, or a consultant who knows Business Central and, ideally, your system? Does the person who built your extensions still look after them, or has the project team moved on and support is a different department with no history? How many people on the support desk have seen your configuration?

Ask for the names. Ask how long they have been there. Ask whether you can talk to the same person about the same problem twice. A good partner's answer is a short list of people you will come to know.

What should be included

This is where contracts vary most. These should be in the monthly fee, not billed as extras:

• Release wave management. Reading the release plan, checking your extensions compile, running the ISV compatibility checks, telling you what will change on screen, and choosing the update date with you. We wrote up the full checklist; a support partner that does not do this twice a year is leaving the update to chance.
• A sandbox refreshed on request, so you can test things safely, and help using it.
• Licence review, at least annually: who is on Premium who only needs Essentials, who has a full licence and only reads reports, which licences belong to people who have left. A good partner tells you when you are over-licensed, which costs them revenue. That is how you know they are a good partner.
• Admin centre and environment management. Users, permissions, environments, storage, telemetry. Someone should be watching the storage graph and the failed job queue entries before you notice.
• Small changes. A new report layout, a new dimension value, a field on a page. Many contracts include a bank of hours or a monthly allowance; make sure it is enough for the routine things and that unused hours roll for at least a quarter.
• "How do I" questions, without a meter running. If your users are afraid to ask because every question is billed, they stop asking and start working around.
• An account review, quarterly or at least twice a year: what went wrong, what you are working around, what is coming up, what the roadmap says. Not a sales meeting.

What is reasonably extra

New development, new integrations, new modules, training courses, projects. The line between "small change" and "development" is the one to agree up front, with examples, so the argument does not happen on the invoice.

What good partners do without being asked

• Tell you about a Microsoft change that affects you before it lands, not after it breaks something.
• Notice a pattern in your tickets (three people asking the same question, the same job failing every Monday) and fix the cause rather than the symptom.
• Put a senior person on a P1, immediately, and tell you who it is.
• Say "that is not worth building" when it is not, and "that is standard, let me show you" when it is.
• Keep your extension source in a repository you own, documented, and hand it over without fuss if you ever leave.
• Own a problem that sits between them and an ISV or Microsoft, rather than bouncing you between the three.

Warning signs

• Every ticket is answered by someone different, and you explain your setup each time.
• The monthly report never arrives, or arrives and shows only tickets closed.
• The update happened and you found out from the login screen.
• The fee goes up every year and the service does not.
• The answer to most questions is a quote.
• Your users have stopped logging tickets. That is not because everything works.
• You ask for your source code and there is a delay.

Questions to ask before you renew

1. Show me last year's actual response and resolution figures against the contract.
2. Who are the three people who have worked on my system most, and are they still here?
3. What did you do for my last two release waves, and what will you do for the next?
4. When did you last review my licences, and what did you recommend?
5. What is included in the fee that I have not used, and why not?
6. If I left, what would I receive, and how quickly?

If those answers are good, renew. If they are not, the market has plenty of partners who will give you good answers, and moving support is a much smaller project than people fear: a handover of the source code, the documentation and the admin centre, and a month of overlap.

Our support is two-hour response, from the people who built the system, with release waves, licence reviews and sandbox management included, and a quarterly review that is about your business rather than ours. If your renewal is coming up and you would like a comparison, send us the contract and we will tell you honestly what we would do differently, including if the answer is "nothing".

More from the blog

• How to log a Business Central support ticket that gets fixed first time Operations
• Continuity is king: why you want the same consultants from the first workshop to the last support call Projects
• Ten Business Central support tickets you do not need to log Operations