The previous post was about the tickets you should not log. This one is about the ones you should, and how to log them so they are fixed first time. Because the single biggest factor in resolution time is not the support desk's skill or their response target; it is whether they can start work on the ticket as it arrived, or have to come back and ask.
Every question they have to ask costs a round trip: hours if you are at your desk, a day if you are not, longer over a weekend. "Posting is broken, please fix" is a ticket that will generate four questions before anyone looks at the system. The same ticket with the right information attached is one the consultant can reproduce in ten minutes. Help them, and they will help you faster.
What they need, and where to find it
- Which environment. Production, or the name of the sandbox. Many businesses have several, and a problem in a sandbox copy is a different conversation from one in production. It is in the top left of the client (the environment name appears next to the company name) and in the URL after
/.
- Which company. If the tenant has more than one company, say which. Settings and data differ by company; a posting setup problem in one company may not exist in another. It is shown at the top of the page and in My Settings.
- Your user ID, and whether the problem happens for other users too. The support desk will want to look at your permission sets, your User Setup (allowed posting dates, your default company), your role centre and your personalisations. "It works for Sarah but not for me" is a permissions or setup clue; "it happens for everyone" is not. Your user ID is in My Settings.
- Exactly what you were doing. The page you were on (its name, and the page ID from Page Inspector, Ctrl+Alt+F1, if you can), the record (the document number, the customer number, the item number), and the action you took (Post, Release, Print, the specific button). Step by step, in the order you did it, so the consultant can do the same thing.
- The exact error message. Copy the text from the dialog (there is a Copy Details link on most error dialogs; use it) or paste a screenshot. Do not paraphrase: "something about dimensions" and "Select a Dimension Value Code for the Dimension Code DEPARTMENT for G/L Account 7100" are the same ticket and the second one is already half solved. Include any error ID or GUID shown; the support desk can search telemetry on it.
- When. Date and time, to the minute if you can. Business Central's telemetry is time-stamped; with your user ID and the time, the consultant can find the exact event in Application Insights without reproducing anything.
- Whether it worked before, and what changed. Did this work last week? Yesterday? Has there been an update (the version is under Help & Support), a new extension, a setup change, a new user, a new supplier, a new item? "This started after the October update" is the most useful sentence in a ticket.
- What you have already tried. Reread the record, tried another user, tried another company, checked the ten common messages. Saves the consultant suggesting them.
- Business impact and urgency, honestly. "Cannot post sales invoices, month-end is Friday" is a different priority from "a report column is misaligned". Say which, and say what the workaround is if you have one. Over-prioritising everything means the support desk stops believing the priorities.
- Is it reproducible? Every time, or once? On this record only, or any record? If you can make it happen on demand, say the steps; if you cannot, say so, and give the time of the last occurrence (point 6).
- Who to contact and when. The person who had the problem, not the person who logged it, with a phone number and the hours they are available. Half of resolution delays are the consultant waiting for someone who has gone home.
- Attachments. The screenshot of the full screen (not a crop of the dialog; the page behind it matters), the copied error details, the document or report output if relevant, and the record's link (the client has Share → Copy Link on most pages, which takes the consultant straight to it).
A template to copy
Put this in your help desk tool as the ticket form, or in a note on every super user's desktop:
Environment: Production / Sandbox name
Company:
User ID: (and: happens for other users? yes / no / not tested)
Date and time:
Page and record: e.g. Sales Order 101234, Sales Order page (ID 42)
What I did: 1. ... 2. ... 3. ...
Exact message: (copied text or screenshot, incl. any error ID)
Worked before? yes, until ... / no, first time
What changed: update / new app / setup change / new data / nothing known
Already tried:
Reproducible? every time / sometimes / once
Impact: who and what is stopped; workaround if any
Contact: name, number, hours
Attachments: full screenshot, error details, record link
The things that slow a ticket down
- "It doesn't work." With nothing else. Round trip one.
- A cropped screenshot of the dialog. The consultant cannot see the page, the record, the company or the environment. Round trip two.
- The ticket logged by someone other than the person who had the problem. Every question has to go through a relay.
- Several problems in one ticket. They get fixed at the speed of the slowest and closed when the first one is.
- A priority that does not match the impact. Either way.
- No reply to the consultant's question for two days. The ticket goes to the bottom of the pile, correctly.
- Fixing it yourself after logging and not saying. The consultant spends an hour reproducing something that is no longer there.
Why it is worth the two minutes
A well-formed ticket is usually resolved in one exchange: the consultant reads it, finds the event in telemetry or reproduces it on the record, fixes the setup or raises the defect, and replies with what they did. A badly formed one takes three or four exchanges to get to the same starting point, and each exchange is measured in hours. If you pay for support by the hour or by the ticket, the difference is money as well as time; if you have a fixed contract, it is the difference between a two-hour fix and a two-day one. Either way, the person filling in the form is the one who benefits.
Super users should own this: they log the external tickets for their department, in this form, and they are the contact. It is one of the reasons the super user role pays for itself. And if your support partner does not have a ticket form that asks for this information, that is worth raising with them; see what to expect from your support partner.
Talk to usWant this done in your Business Central?
More from the blog
