Service Request and Ticket Resolution

Why do two identical requests resolve at completely different speeds?

Request raisedThe customer asks
Request closedThe customer is served

Why this process resists visibility

Ticketing systems are excellent at recording state and poor at recording journey.

  • Status is not a journey

    Open, pending and closed describe where a ticket stands. They rarely show the reassignments, the parallel escalation or the second team that repeated the first team's diagnosis.

  • Pending stops the clock, not the wait

    Time spent on hold disappears from the service measure while remaining fully present in the customer's experience of it.

  • First-time fix is self-reported

    Tickets reopened, duplicated or raised again on another channel are rarely reconciled back to the original, so repeat work looks like new demand.

  • Channels do not reconcile

    The same issue arrives by phone, portal, chat and email as separate records, and the volume of distinct problems can be materially smaller than the queue suggests.

  • Routing is learned, not designed

    Work reaches the right person through informal knowledge of who fixes what, which functions well until that person is unavailable.

Where time and effort accumulate

The process is normally drawn as six clean stages. Execution data shows what actually collects at each one, and how much of the cycle is spent waiting rather than working.

  1. Stage 1

    Intake and channel

    • One issue raised on several channels
    • Duplicate tickets for one problem
    • Misclassification at the point of capture
    • Requests arriving without the detail needed to act
  2. Stage 2

    Triage and categorisation

    • Categories applied inconsistently
    • Priority set by the requester rather than by rule
    • Recategorisation later in the ticket's life
    • Queue chosen by habit
  3. Stage 3

    Assignment and routing

    • Tickets waiting unassigned
    • Work bounced between teams
    • Skills-based routing overridden manually
    • Escalations opened in parallel to the ticket
  4. Stage 4

    Diagnosis and work

    • The same investigation repeated by a second team
    • Knowledge articles bypassed
    • Changes raised as a separate unlinked record
    • Work paused and resumed across shifts
  5. Stage 5

    Pending and dependency

    • Waiting on the customer, a supplier or a change window
    • Pending used to protect the service measure
    • Reminders sent by hand
    • Dependencies tracked outside the ticket
  6. Stage 6

    Resolution and closure

    • Resolved without customer confirmation
    • Tickets reopened after closure
    • Automatic closure hiding unresolved work
    • Root cause not recorded

What runs underneath all six

These four behaviours recur across the stages and often account for a large share of the cycle: work waiting in a queue without a clear owner, work looping back to a stage it already passed, work changing hands between teams with little record of the handoff, and the same request type running through materially different routes depending on who touched it.

How RE-ViVE observes it

No process remodeling. No new workflow instrumentation. Read-only source access.

You provide the relevant source records and limited subject-matter support. RE-ViVE does the reconstruction and the analysis.

  1. Step 1

    Read-only extracts

    Ticket, contact, assignment and resolution records from the systems that already hold them. Nothing is written back.

  2. Step 2

    Execution reconstructed

    RE-ViVE maps source records into its Execution Data Model, allowing each request to be reconstructed across the systems involved.

  3. Step 3

    Followed end to end

    Each request can then be followed from request raised to request closed, with dwell time, loops and handoffs measured rather than estimated.

  4. Step 4

    Kept current

    The view refreshes as new requests are recorded, so the effect of any change is visible in the same measure.

What you are left holding

Evidence specific enough to act on, and traceable back to the individual request behind it.

  • The routes requests actually take

    Every path present in the data, broken out by category and channel and ranked by volume and by the effort it consumes.

  • Where the days sit

    Elapsed time split between active work, queue waiting and pending, so the customer's experience and the service measure can be compared.

  • Repeat work made countable

    Reassignments, repeated diagnosis, duplicates and reopened tickets, counted and costed rather than reported as fresh demand.

  • Cause attributed

    Delay and repeat work attributed by category, channel, team, site, asset and requester group.

  • Service exposure explained

    Where commitments are missed, and which part of the route created the miss rather than which team was holding it at the end.

  • A monitored process

    Continuous visibility once the first view is built, giving a baseline that deflection, automation and knowledge changes can be measured against.

Where the evidence lives

Service Request and Ticket Resolution leaves a record in systems you already run.

  • IT and enterprise service management
  • CRM and contact centre
  • Telephony and chat
  • Knowledge base
  • Change and asset management
  • Field dispatch
  • Monitoring and alerting
  • Customer feedback

RE-ViVE works with the systems an enterprise already runs, including platforms such as ServiceNow, Jira Service Management, Zendesk and Salesforce Service Cloud, along with other service platforms, telephony, chat, monitoring tools and custom applications. Where execution moves outside the available system evidence, RE-ViVE makes the unexplained interval visible for investigation.

Processes next door

Service requests share their evidence with the processes that generate them.

See how your requests actually resolve

Give us read-only access to the ticket data you already hold, and we will show you the routes, the waiting and the repeat work inside it.

See all processes