How to write a support case that gets solved first time

Most support cases stall because the consultant has to ask the same follow-up questions before work can begin. That costs time, and time is either your hours or your waiting. A case that is well written the first time can often be solved without a round trip. This article shows what a consultant needs to know and gives you a template you can reuse.

Write what happened and what you expected

Start with two sentences. What were you trying to do, and what happened instead? Do not write 'it doesn't work'. Write, for example: 'I post a sales invoice and the system reports an error.' Then the consultant knows where to look.

Add what you expected to see. The difference between what was expected and what happened is often the problem itself.

Keep one case to one problem. If you have three errors, create three cases. They can then be prioritised separately, and a small fix does not wait behind a big one.

Copy the error text word for word

The error text in Business Central is often the most important thing the consultant gets. Copy it instead of rewording it. On the error message you can usually choose to see more details, and these often contain a timestamp and a technical description. Include them.

According to Microsoft Learn, the message 'Sorry, we just updated this page' often has a simple cause: two users changed the same data at the same time. So always say whether anyone else was in the same document.

If the error comes and goes, say so, and say what is common when it appears: the same customer, the same item, the same user or the same time of day. Patterns are often the key. If only one person experiences it, say that too.

Describe the steps so they can be repeated

A consultant can usually fix an error only once it can be reproduced. So write step by step what you did:

Which page or document you were on, and the document number
Which fields you filled in and which values you chose
Which button or action you used
What happened immediately afterwards

Environment, user and screenshot

Business Central typically has a production environment and one or more sandbox environments. Say which environment the error is in and which company. Also say which user experienced it and what role the user has, because permissions are often part of the explanation.

State when it last worked and whether anything has happened since: an update, a new app, a changed setup or a new user.

A screenshot of the whole window is better than a cutout. It shows the page name, filters, company and the fields that are filled in. Hide personal data if the case goes to an external partner without a data processing agreement. See also the article on data processing agreements.

If the case arose after an update, write the date. Business Central is updated at fixed times, and a date can save the consultant a long search.

State the urgency and the consequence

Say what the error prevents: can you not invoice, or is it an annoyance? That information is used to prioritise the case. See the article on response time and SLA for how priorities should be defined.

You can use a fixed template, so everyone in the company writes cases the same way.

Also write what you have tried yourself and whether there is a workaround. A consultant who knows you have already tried signing out and in, or using another user, can skip those steps. Give a phone number or a time when you can be reached if the case is urgent.

At Addverk

We have gathered our support offering on the page about services and prices. Whoever you choose, you get the most out of a good case description.