Own Business News – Updates for Entrepreneurs
Business

Service desk reports: build a baseline before changing platforms

A backlog that shrinks after an IT service management (ITSM) platform change raises a question: did the team clear more work, or did the report change what it counts?

Service desk reports connect incoming demand, completed work, and outstanding workload. A baseline established before the move lets managers compare results using consistent counting rules.

Define the population and reporting period

Start with the report’s boundaries: included queues, ticket types, reporting dates, cutoff time, and time zone. Specify whether outstanding work includes tickets waiting for users or external teams. Give events at the cutoff a clear allocation rule so each belongs to one reporting period.

For teams evaluating European ITSM options such as Matrix 42 ITSM, that baseline becomes a set of reporting requirements: the ticket fields, history, and counting rules the replacement must support.

Report incidents and service requests separately, even if management also receives a combined total. A shift toward routine requests can change the overall picture while performance within each category stays the same.

Choose the status that marks completion, including how tickets awaiting confirmation are treated. That decision determines which work remains in the backlog.

Build a report that explains the backlog

Opening and closing backlog are snapshots. New tickets, reopenings, and completions describe activity between them. Showing both explains how the outstanding workload changed during the reporting period.

Consider this hypothetical weekly report for one service-request queue. Waiting tickets remain unresolved, transfers are zero, and all movements are listed below:

  • Opening backlog: 80. Unresolved tickets at the start of the week.
  • New tickets: 120. Newly created tickets entering the queue’s unresolved workload during the week.
  • Reopened entries: 5. Transitions from completed back into unresolved work.
  • Completion exits: 130. Transitions out of unresolved work through the agreed completion status.
  • Other removals: 3. Unresolved tickets canceled or merged away, excluded from completion exits.
  • Closing backlog: 72. Unresolved tickets at the end of the week.

The balance is 80 + 120 + 5 − 130 − 3 = 72. Check that the independently counted closing snapshot also shows 72.

The activity figures count entries and exits rather than distinct ticket IDs. One ticket can be completed, reopened, and completed again during the week. Both completion exits belong in this calculation.

Where transfers occur, show entries into and exits from the included queue group separately. Moving a ticket outside the reported group reduces that group’s backlog while leaving the work outstanding elsewhere.

Alongside the total, show the age of unresolved tickets. One possible split is younger than seven days versus seven days or older, measured from original creation to the cutoff. This is a reporting choice, not a performance standard. Under that definition, a reopened ticket is still measured from its original creation date.

Keep comparisons consistent across platforms

Test the baseline definitions against the replacement platform before interpreting its trends.

Suppose the old report includes resolved tickets until final closure, while the new report removes them at resolution. The new backlog figure could fall simply because work awaiting confirmation has moved outside the count. Reproduce the original definition where possible; otherwise, identify the break clearly.

Changes in queue boundaries or reporting windows also need annotation. Adding another support team expands the population, while moving the cutoff shifts activity between periods. Record these changes beside the figures.

Historical comparisons depend on a ticket’s status and assignment at the relevant cutoff. A ticket now assigned elsewhere could have belonged to the reported queue then. Reconstructing that position may require status history, assignment history, or a saved snapshot. Preserve the original report and its definitions before switching systems.

If the required history is unavailable, mark the break and start a new baseline rather than presenting incompatible figures as a continuous trend.

Explain the change, then assign an action

Give each report a short interpretation and a question to investigate. If total backlog falls while older unresolved work grows, identify the requests that are aging and their blockers. When transfers account for most of the reduction, follow the work into the receiving queues.

Assign an owner and a review date. At the next review, use the same definitions to show what happened to that work and decide whether the action needs to change.

Related posts

IP Phone Systems to Help you Communicate Almost Everywhere

Quincy Roger

How A Few Thoughtful Changes Can Improve a Uniform

Quincy Roger

How to File An Annual Report

Quincy Roger