A customer writes: “This is not working properly. Please fix it as soon as possible.” This request feels urgent, but you do not have enough detail to act. What is not working? For whom? When did it start? What does the customer hope for? You should not prioritize or promise response time yet. You must first translate the request into a concise, factual summary that you and someone else can easily understand without guessing.
There should be a distinction between the customer request and the service task. The customer request is not to be altered, but the service task needs rephrasing to be more structured. You need to identify: customer need, affected service, observed problem, impact, requested outcome. The preceding customer request should be rewritten as: “A customer is unable to complete checkout because the payment page does not load once the credit card details have been input. The problem started this morning and prevents all purchases.” Now the service team has something specific to investigate.
Urgency and impact should be captured separately. Just because the customer’s message feels urgent, does not mean it must take precedence over other requests. Impact refers to how much of a service is impacted, whereas urgency means how much time is available for a task. A minor cosmetic issue impacting just one person may seem urgent to the one person who is experiencing that issue, while a payment failure affecting every customer has a significant operational impact. Beginners can benefit from using a priority matrix to aid in decision making instead of using a vague sense of urgency.
Another important aspect of a service task is ownership. A service request should not be circulated without visible ownership. Document who is currently investigating the problem, what the next action is, and when the customer can expect the update. Service task ownership does not imply a single individual is responsible for all back end work. Ownership means that someone needs to be accountable for seeing the request through handover and resolution confirmation, including any escalation. Service tasks can get lost if this responsibility is lacking, even if the request is well-written.
To try this out, take 3 customer requests, either taken from a request log or by creating your own, and rewrite each 1-2 sentences factually. Remove any interpretive emotions, but add any necessary details to describe the customer situation. Then mark the affected service, potential categorization, urgency, impact, ownership, and follow-up details. If anything on the above list requires a guess, this request is not fully developed and you must write 1 question you could ask the customer to gain further details rather than making that assumption yourself.
Be careful that request intake does not turn into a survey. Gather only the necessary information that allows you to make a reasonable decision about next steps. If a request is too detailed, you overwhelm the customer and create excessive request content, but if you do not have enough details you cause confusion. A simple self check: if you came back to the request and read it could you tell what the issue was, who was affected, what has been attempted and what should happen next. If not, you either need to tighten the wording on the service request or ask 1 targeted question.
You will know you are on the right track when the volume of back and forth clarifying emails and handover meetings is noticeably lower. The aim is not to write long service tickets, but rather to have enough information to be able to prioritize, assign, follow up on and eventually confirm that it is resolved. Next time a customer tells you, “It is broken”, resist the urge to say, “I will get back to you ASAP”, and first reframe the request into a service request that is ready to be acted upon.
