We're solving the "forgotten ticket" problem

Ticket sync is meant to solve a simple problem.

Two organisations share responsibility for IT support, but they live in different systems. One team works in an ITSM like ServiceNow or Freshservice, the other works in a PSA like Halo or ConnectWise. Without integration, everyone spends their day retyping updates, copy-pasting comments, and chasing reference numbers across portals.

So we sync.

Tickets appear on both sides. Status changes flow. Comments follow. Everyone stays in their preferred system.

And then an awkward question shows up in the real world.

If a ticket wasn’t synced, did it ever really happen?

Enter the forgotten tickets

The problem usually does not appear on day one.

It shows up when service models change.

A provider moves from a dedicated service desk to a shared or hybrid team. Tier-one agents are now supporting multiple customers, from one primary tool. They can no longer live inside every customer’s system.

That is when forgotten tickets start to appear.

These are tickets that:

• Exist in the customer system

• Matter to the end user

• May resurface days, weeks, or months later

• But never made it into the provider’s system

As one service delivery leader described it:

“The use case is… a user has an existing ticket that didn’t necessarily originate from a phone call… they call in and ask about it.”

The ticket exists. The customer can see it. The user remembers it.

But the service desk cannot find it, because it was never part of the original sync.

Why forgotten tickets happen

Forgotten tickets are not usually the result of a broken integration.

They are the side-effect of a deliberate decision.

To keep service desks usable, most providers scope integrations carefully. They sync only the tickets they are responsible for, based on assignment group, queue, service, or ticket type.

This is the right move.

The alternative is the firehose.

“I’ve got thousands of open tickets that aren’t ours… that aren’t conveniently sorted out of our views.”

Sync everything “just in case” and you gain visibility at the cost of clarity. Backlogs inflate. Dashboards lose meaning. Agents waste time sorting what they own from what they merely observe.

So teams do the sensible thing.

They avoid the firehose.

And that is how forgotten tickets are created.

The two bad defaults

When teams realise forgotten tickets are becoming a problem, they tend to fall into one of two bad defaults.

1. Sync everything anyway

This ensures forgotten tickets do not exist, because nothing is excluded.

It also ensures the PSA becomes noisy, cluttered, and hard to operate. Over time, this erodes closure discipline, SLA reporting, and team confidence in the system.

2. Accept that history is fragmented

This keeps the PSA clean, but forces agents back into customer tools whenever an old issue resurfaces.

In practice, this often leads to awkward workarounds:

“That queue emails our ticketing system… just to tell our team to log into the client’s system and get the ticket.”

Neither option scales well.

Why “single pane of glass” usually disappoints

The instinctive response to forgotten tickets is to ask for a single pane of glass.

A portal. A dashboard. A warehouse of all tickets across all customers.

In reality, this often fails because:

• It creates a new system without clear ownership

• It adds another interface for teams to learn

• It blurs accountability boundaries defined in contracts

• It provides visibility without responsibility

Forgotten tickets are not a data problem. They are a service delivery problem.

A better way to think about forgotten tickets

The model we believe works best has two parts.

1. Be intentional about what flows

Tickets should only flow between systems when there is a clear service responsibility.

This keeps the provider’s system operationally clean and aligned to the contract.

2. Make forgotten tickets retrievable when they matter

When an old or excluded ticket suddenly becomes relevant, the service desk needs a way to:

• Look it up by reference

• See enough context to understand the situation

• Pull it into their system only when needed

As one operator put it:

“A search… where I can take this ticket and bring it into our system now. So I can work on it.”

This approach avoids flooding the service desk, while ensuring forgotten tickets do not stay forgotten.

What this needs to work in practice

For forgotten ticket handling to be genuinely useful, it has to:

• Work quickly during live calls

• Respect access and contract boundaries

• Avoid adding licensing pressure across customer systems

• Keep pulled tickets clearly separated until ownership is taken

This is not about perfect history. It is about practical recovery of context.

Forgotten tickets are a scaling signal

Almost every MSP or service provider hits this problem eventually.

Not because something failed, but because they grew.

Shared teams, hybrid delivery, and modern ITSM platforms force a re-think of how information moves across organisational boundaries.

Forgotten tickets are a sign that your service model has evolved.

The question is whether your tooling evolves with it.

Where we are heading

Support Fusion was built to keep teams working in their own systems, without drowning in duplicated data.

Today, that means selective, contract-aware ticket flow.

Going forward, it also means addressing forgotten tickets in a way that preserves clarity, accountability, and service quality.

This is an active part of our journey, shaped by real conversations with service delivery leaders facing these problems every day.

Want to be part of that journey?

If forgotten tickets sound familiar, we’d love to talk.

• Book a demo to see how Support Fusion handles cross-platform service delivery today

• Join our community to follow our thinking, roadmap, and real-world learnings as we work through the hard problems in managed IT services

Because in service delivery, nothing is more frustrating than work that existed… but somehow got forgotten.