Customer churn rarely happens from a single event. Usually, it happens silently after a few unanswered requests.
Requests come in via phone, email, and messaging; when there is no record of who promised what, tracking becomes impossible.
In this article, we explained the service request workflow, priority setup, and SLA tracking.
Table of Contents
What is a service request?
A service request is a record where a customer communicates a problem or a request. Unlike a verbal promise, the record itself can be tracked.
Every request has a number, an owner, a status, and a date. These four pieces of information form the basis of tracking.
Work done without opening a request remains invisible. The team's actual workload can only be measured through records.
Therefore, requests coming in by phone must also be entered into the system; work left unrecorded is both unmeasurable and forgotten.
Requests are managed in the CRM module.
Request workflow
The workflow begins with the opening of the request. During the opening, the customer, subject, and description are recorded.
Then classification is done; the type of request determines the next steps.
A responsible person is assigned during the allocation stage. An unowned request is an unresolved request.
Actions taken during the resolution process are recorded; every piece of information given to the customer must also be noted.
Closure must be done with customer approval. Requests closed unilaterally hide dissatisfaction.
Prioritization
Priority is the combination of two dimensions: the magnitude of the impact and urgency.
A breakdown that stops production and a cosmetic request cannot have the same priority.
Priority rules must be written; otherwise, the customer who demands the loudest gains priority.
The customer segment can also play a role in priority; however, this must be defined as a rule and be transparent.
Priority is determined at the time of opening and escalated when necessary; every change must be recorded with its justification.
What is an SLA and how is it defined?
SLA is a service level commitment. It determines how quickly a request will be answered and resolved.
Two different timeframes must be defined: first response time and resolution time. The two are very different commitments.
Timeframes vary according to priority. The first response time for a critical request should be shorter than that of a low-priority request.
Working hours must also be included in the definition; if closed on weekends, the time calculation must be made accordingly.
We discussed the target-setting method in the SLA targets article.
Assignment and escalation
Assignment is the delivery of the request to the right person. Wrong assignment wastes time.
Automatic assignment rules can be established; routing is done according to the request type or customer group.
Escalation comes into play when a time breach approaches. The responsible person and their manager are alerted.
The warning must come before the breach; a warning that comes after the breach has occurred is merely a report record.
We explained these setups in the automation rules article.
When field intervention is required
Some requests cannot be resolved remotely and require on-site intervention. In this case, the request turns into a work order.
The work order includes the technician, the scheduled date, and the required parts.
Travel time must also be included in the SLA calculation; different timeframes can be defined for remote locations.
Parts used after the intervention should be deducted from stock and invoiced if necessary.
We covered the field work order workflow in the work order tracking article.
Reporting and improvement
The purpose of SLA tracking is not to penalize, but to find recurring problems.
The most frequently opened request types show which areas need improvement.
When requests with breaches are examined, a systemic cause is often found: missing information, insufficient resources, or unclear processes.
Customer-based request density should also be monitored; an accumulation at a single customer indicates that the relationship is at risk.
We covered satisfaction measurement in the CSAT article.
Channel management
Requests do not come from a single channel. Phone, email, messaging apps, and site visits are all sources of requests.
Having a separate queue for each channel hides the team's true workload and makes prioritization impossible.
Therefore, all channels must be consolidated into a single request pool. The source information should be stored on the record.
Source information turns into valuable data over time, making it visible which channel brings which type of request.
Requests coming by phone are the group that most frequently remains unrecorded. The habit of opening a record during the call closes this gap.
We covered collecting channels in a single place in the unified inbox article.
Knowledge accumulation and recurring issues
Most support teams answer the same questions over and over. This repetition is a source of both wasted time and inconsistency.
Keeping resolution records structured turns this information into the team's shared asset.
Canned response templates can be defined for frequently encountered issues; this increases both speed and consistency.
The root cause of recurring requests must also be addressed. Solving the same problem a hundred times is more expensive than eliminating it once.
For this, it is sufficient to periodically group request types and examine the top three most intense categories.
A fix made on the product or process side permanently reduces the support load.
Frequently asked questions
Can requests be opened automatically from email?
Channel integration can be configured; we determine the scope together during the setup phase.
Can the customer see the status of their request?
This is possible through notification messages; we evaluate the scope of the customer portal according to your needs.
Can the SLA timer be paused?
Pausing can be defined during periods awaiting information from the customer; this is necessary for fair measurement.
Can it be associated with a maintenance contract?
It can be associated; maintenance contract management check out the article.
Service request management is the framework that records the most fragile point of the customer relationship. A request that is not recorded turns into a request that is not resolved.
Be realistic when defining SLAs. A commitment that cannot be kept does more damage than making no commitment at all.
Set up alerts before the breach occurs; an alert that comes after is just carrying bad news.
Ensure that requests coming in by phone are also recorded. Work that is not recorded cannot be measured and hides the team's true workload.
Review recurring request topics periodically; eliminating a problem once instead of solving it a hundred times is always cheaper.
By talking to the EQLEM team you can plan your support processes.