Issue-to-Resolution(I2R)
From customer request to resolved complaint: how the issue-to-resolution process runs, how it is measured and where tickets get stuck between channels, teams and support levels.
Also known as: I2R · Issue to Resolution · Case-to-Resolution · Ticket-to-Resolution · Complaint-to-Resolution · Customer service process
What is Issue-to-Resolution?
Issue-to-resolution (I2R) is the end-to-end process from receiving a customer issue to its final resolution. It covers capture via phone, email, chat or portal, classification and prioritisation, assignment to a team, handling with escalations and hand-offs between support levels, the solution, closure and customer feedback. It includes service requests as well as complaints and warranty claims. Because customers judge service by the outcome and by how long they wait, I2R has a major influence on satisfaction and retention.
Starts with
A customer raises an issue through a channel and a ticket is created.
Ends with
The issue is resolved, the ticket closed and the feedback recorded.
Typical phases
- 1
Capture
Issues arrive by phone, email, chat, portal or field service and are created as a ticket or case, ideally linked to customer, product and order.
- Request received
- Ticket created
- Customer & order linked
- 2
Classification & assignment
The ticket is classified by type, urgency and contract; this determines priority, SLA and the responsible team.
- Category set
- Priority assigned
- SLA attached
- Assigned to team
- 3
Handling & escalation
First level resolves what it can and passes the rest to second level, a specialist department or the manufacturer. Queries to the customer and escalations interrupt the work.
- Work started
- Query to customer
- Handed to second level
- Escalation
- Solution found
- 4
Resolution & closure
The solution is delivered – as information, repair, replacement or credit note – and communicated to the customer. The ticket is then closed, or reopened if the problem returns.
- Solution communicated
- Credit note or replacement triggered
- Ticket closed
- Ticket reopened
- 5
Feedback & review
Customer satisfaction is surveyed, and recurring causes are reported back to product, quality or logistics.
- Survey sent
- Rating received
- Root cause reported back
Business objects and systems
These are the objects the process leaves in the source systems – with timestamps, owners and relationships to each other.
- Ticket / case
- The customer issue with channel, category, priority, status and handling history.
- Customer & contract
- Who raises the issue and which service agreement applies to it.
- Interaction
- Every contact on the ticket – call, email, chat message, query or reply.
- SLA
- Agreed response and resolution times per priority, with clock, pauses and breaches.
- Complaint & warranty claim
- Issue about a delivered product, linked to order, delivery and invoice.
- Credit note / replacement
- The commercial or logistical consequence of a justified complaint.
Typical source systems
- Customer service and ticketing systems (e.g. Salesforce Service Cloud, ServiceNow CSM, Zendesk)
- CRM systems
- Contact centre and telephony platforms
- ERP for orders, deliveries, credit notes and warranty
KPIs that can be measured
- Time to resolution
- Time from receiving the issue to its resolution.
- First contact resolution
- Share of issues resolved at the first contact without a hand-off.
- SLA adherence
- Share of tickets whose response and resolution times stay within the agreement.
- Reopen rate
- How many closed tickets have to be opened again.
- Hand-offs per ticket
- How often a ticket is passed between teams or support levels.
- Customer satisfaction
- The customer’s rating after closure, e.g. as CSAT or Net Promoter Score.
Typical problems
Ping-pong between teams
Misclassified tickets bounce between teams and support levels. Every hand-off starts a new queue without anyone working on the issue.
SLA clocks that flatter the numbers
Tickets are set to “waiting for customer” to pause the clock, or closed prematurely. SLA adherence in the report then no longer matches how long the customer actually waited.
Reopened and duplicate tickets
Unresolved issues come back as a reopened ticket or as a new case through another channel – and are then counted separately.
Causes outside customer service
Many complaints originate in delivery, billing or product quality. Without a link to order and invoice, service stays with the symptom.
How Noreja analyses Issue-to-Resolution
A ticketing system shows status changes, not the whole issue. The same customer gets in touch by email and phone, a case is split or merged, a complaint is tied to an order, a delivery and a credit note. Noreja connects tickets, interactions, customers and the documents from the ERP in the event knowledge graph instead of treating each ticket as an isolated case in a flat event log.
The intended flow – classification before assignment, escalation by fixed rules, a query to the customer before the SLA clock is paused, closure only after the customer has confirmed – is modelled as the expected order with domain knowledge from customer service. This shows where tickets leave that path and which deviation leads to reopened cases.
Questions Noreja answers
- Which categories and channels breach SLAs most often?
- Which tickets are passed back and forth between teams several times?
- How long do tickets sit after a hand-off before anyone works on them?
- Which solutions lead to a reopened ticket particularly often?
- Where is the SLA clock paused although the customer was never asked?
- Which orders, deliveries or invoices trigger the most complaints?
Matching agents from the Minerva Agent Library
Frequently asked questions about Issue-to-Resolution
What is the issue-to-resolution process?
Issue-to-resolution (I2R) is the end-to-end process from receiving a customer issue to its resolution. It covers capture, classification, assignment, handling with escalations, resolution, closure and feedback – for service requests as well as complaints and warranty claims.
What is the difference between issue-to-resolution and request-to-fulfill?
Request-to-fulfill describes internal IT service requests, such as access, hardware or software, from a service catalogue. Issue-to-resolution concerns the issues of external customers – questions, faults, complaints – and is measured by their waiting time and satisfaction.
How are issue-to-resolution and order-to-cash connected?
Complaints about deliveries or invoices originate in the order-to-cash process and feed back into it: as a credit note, a replacement delivery or a blocked payment. Connecting both processes shows which orders trigger the most service issues.
Which KPIs matter in issue-to-resolution?
Typical KPIs are time to resolution, first contact resolution, SLA adherence, the reopen rate, hand-offs per ticket and customer satisfaction after closure.
Demo cases with a worked-through analysis
End-to-end processes we have played through with findings, causes and measures – some of them touching Issue-to-Resolution.
- Touchless order processingOrder-to-CashHow causal process mining shows which customer orders can run touchless – and where a targeted review protects quality.
- District heating connectionLead-to-ActivationFrom first customer interest to start of supply: how process intelligence exposes rework, seasonal construction times and compliance risks in district heating connections – and turns them into prioritised measures.
Understand your process causally — talk to us
Join companies that are redefining growth and efficiency with intelligent process analysis.