كيف تحوّل ملف تصدير تذاكر ServiceNow أو Jira إلى تقارير SLA يثق بها مجلس إدارتك

Most SLA reports I am asked to review have the same weakness. The number came out of the ITSM tool, nobody can say which schedule produced it, and the one person who could explain it has left.

A ticket export fixes that, because it holds the raw timestamps. You can count them yourself, on a clock you chose, and show the board how you got there. It takes an afternoon the first time and ten minutes after that. This is the order I do it in.

1. Export the fields the report needs

You need six things per ticket: when it was opened, when it was resolved, its priority, its category, the ticket number and, if the tool records one, whether the SLA was met. Two more make the report far better: the assignment group and a reassignment count.

These are the header names the service desk dashboard looks for. Where a tool has no matching column, the cell is blank.

ServiceNow: add the columns to the Incident list, then right-click a column header and choose Export, CSV. Jira Service Management: search with JQL for your project and date range, show the fields, then export CSV with the current fields. Freshservice: filter the tickets by date, then Export, and tick the fields.

Two choices at this step decide most of what follows.

Export a long enough window. Three months at least, six if you can. A single month is too short to show a trend, and with 15 P1s in it, one ticket moves the P1 figure by almost seven points.

Export tickets, not events. Some audit and history exports hold one row per update. The dashboard keeps the latest row for each ticket number and tells you how many it dropped, but check the count of unique tickets against what the tool's own list view shows. If they disagree, the export filter is wrong, not the data.

2. Decide whose clock you are counting on

This is the step that makes an SLA report trusted or not.

If your export has an SLA column such as made_sla, the dashboard uses it. That is the tool's verdict, which means it reflects whatever schedule the tool was given and whatever pauses agents applied. If the export has no such column, the dashboard measures each resolved ticket against the target you set for its priority, on the calendar you choose.

I do both when I can, and the gap between the two is often the best finding in the report. If the tool says 94% and the timestamps on a Sunday to Thursday calendar say 88%, something is wrong: the schedule, the pauses, or the targets themselves. A report that shows only one of the two hides the thing the board most needs to hear.

Here is why the calendar matters in the GCC. Take one P2 with an 8-hour target, logged Thursday 10 September 2026 at 14:00, on the GCC business hours calendar presets:

• On the UAE private-sector preset (Monday to Friday, 08:00 to 17:00) it is due Friday 13:00.
• On the Saudi Arabia preset (Sunday to Thursday, same hours) it is due Sunday 13:00.
• On a 24 × 7 clock it is due Thursday 22:00.

Resolve it on Sunday morning and the ticket has met its target in Riyadh, breached it in Dubai and breached it on a 24 × 7 clock. A group that runs one schedule for both countries reports a number that is wrong for one of them. Ramadan hours and public holidays move the due time further; the Ramadan 2027 playbook covers those.

Before you trust any figure, find out which calendar the tool applied to each queue, and whether the Eid dates are in it. Ask the platform owner. If they cannot answer in a minute, that is your first action item.

3. Clean the file before you read it

Spend ten minutes here. It is the cheapest accuracy you will buy.

• Dates. An export with 05/10/2026 in it is either 5 October or 10 May. The dashboard reads every value and decides by looking for a day above 12, then tells you which order it found. Check that line. If the file only has days up to 12, set the order yourself.
• Resolved or closed. Closed dates sit days after resolution, because most tools auto-close after a quiet period. Count on resolved_at, not closed_at, or every ticket looks slower than it was. The dashboard prefers the resolved column and falls back to closed only when there is none.
• Priority labels. Tools name them differently: 1 - Critical, Highest, P1. The dashboard shows how each label in your file was mapped to P1 to P4. Read that list. A custom label it cannot place is treated as a P3, which quietly flatters or punishes a whole queue.
• Open tickets. A ticket with no resolved date is not in the compliance figure at all. It sits in the backlog and the ageing chart. A breach that is still open at the end of the period is not in your 94%, so report open tickets already past target beside it.
• Blanks. Exports mark empty values in several ways (a question mark in ServiceNow, a dash or N/A elsewhere). The dashboard treats those as empty. If you work in a spreadsheet, do the same.

4. Read the report the way the board will

A board will not read a dashboard. It will read three sentences and one chart. Build the three sentences from the numbers in this order.

1. Compliance against the target, with counts. Not "94%", but "94% of 1,200 resolved tickets against a 95% target: 72 breaches, 12 more than the 60 the target allows". The allowance is resolved tickets multiplied by (100% minus the target); subtract it from your breaches. (The 1,200 tickets are an illustrative example.)
2. The weakest priority, not the total. P3 and P4 outnumber P1 and P2 so heavily that they set the total. A healthy 95% can hide a P1 result that is poor. Quote the lowest priority and its ticket count.
3. The direction. Whether logged is running above resolved over the last weeks. A rising backlog is the earlier warning; the SLA figure is the later one.

For the chart, use the SLA-by-priority bars or the backlog trend. Skip the category pie. And use medians, not averages, for resolution time: one ticket left open for 90 days wrecks an average and says nothing about the typical experience.

For how to read a single figure like 87% against a target, see Is 87% SLA compliance good?. It sets out the arithmetic that sits behind sentence one.

5. Finish with one action and one owner

A report that ends in a chart gets nodded at. One that ends with "the Service Owner for the access queue will bring P2 resolution inside target by the end of next month" gets minuted. Pick the single weakest cell, name who answers for it and give a date.

The dashboard prints a one-page A4 monthly service review you can drop into a management pack, with an optional organisation name. Everything is computed in your browser; the file is not uploaded, which matters if the export carries user names or ticket text your security team would rather keep local.

A checklist for your next export

1. Export at least three months, one row per ticket.
2. Include opened, resolved, priority, category and ticket number. Add the SLA column, assignment group and reassignment count if you have them.
3. Check the ticket count against the tool's list view.
4. Check how dates and priorities were read.
5. Choose the calendar the queue actually runs on, and say which one in the report.
6. Compare the tool's own SLA verdict with the timestamp count. Report the gap.
7. Quote compliance by priority, with counts, before the total.
8. Put open tickets already past target beside the compliance figure.
9. End with one action, one owner and a date.

If you want to see what the report looks like before you export anything, open the service desk dashboard and choose "Try it with sample data". It is a built-in example of a retail service desk. If you would rather have a second pair of eyes on your own numbers, that is what an ITSM health check is for.