Run a mock round

I separate the relationship from the facts. Being right is not the goal; resolving the issue is.

I listen fully and acknowledge their perspective: "I can see why you read it that way." Then I present evidence gently and without a tone of correction. Depending on the situation I might show a log, a timestamp or the original terms.

If it is a genuine misunderstanding I explain the policy or behaviour patiently and check it landed. If the disagreement is about something minor and fixing it would cost little, I may simply resolve it rather than win the argument, because preserving the relationship is worth more than the point.

If the customer insists on something we cannot do, I restate the boundary calmly, offer alternatives and escalate if needed. I never argue and I never make them feel stupid. Afterwards I note whether clearer communication could have prevented it.

I measure satisfaction with a mix of metrics, because each has blind spots.

CSAT asks how satisfied a customer was with a specific interaction and is best collected immediately after a ticket closes. It is transactional and easy to act on. NPS asks how likely someone is to recommend us and captures relationship health over time, though it is noisy. Customer effort score asks how easy it was to get help and predicts loyalty well, especially in support. I also track first response time, resolution time, reopen rate and churn.

The numbers only matter if I act on them. I review low scores individually, look for patterns by issue type or agent, and feed product problems back to the relevant team. I segment results so a strong average does not hide a failing customer segment, and I report trends rather than just the latest figure.

I say no to the request, not to the customer.

First I make sure I understand what they actually need, because a request is often a proposed solution rather than the real goal. "You need this feature by Friday" might really mean "I have a deadline and need any workable option."

Then I explain the constraint honestly: policy, technical limitation or capacity. I avoid vague refusals like "that is not possible" and instead give the reason and what I can offer.

I always provide an alternative where one exists: a workaround, a different timeline, a different tier or a self service option.

I keep the tone warm and respectful, and I offer to explore further if the need is critical. If the request is genuinely unreasonable or against policy, I hold the line calmly and consistently, and I escalate for a decision rather than making an exception I cannot repeat.

To me good customer service means solving the customer's problem accurately and making them feel respected throughout.

It has three parts. Competence: knowing the product and processes well enough to give a correct answer the first time, or finding someone who does quickly. Empathy: recognising that the issue matters to them even when it is routine for me, and communicating like a human rather than reading a script. Ownership: taking responsibility until the issue is resolved, rather than passing it around.

It also means honesty. If something will take three days, I say three days, and I set that expectation early. A customer who is told the truth is easier to keep than one who is over promised to.

For me success is when a customer ends the interaction feeling that the company is on their side, not just that a ticket was closed.

I prioritise by impact and urgency, not by who shouted loudest.

First I apply the service level agreement: anything breaching a contracted response or resolution time, or affecting a critical system or many users, comes first. A single user with a cosmetic issue waits behind an outage affecting a whole account.

Then I consider business impact: revenue at risk, safety or compliance, and whether someone is blocked from working. I group similar tickets so one fix resolves several.

I communicate proactively. If a customer will wait, I tell them the expected time and why, which usually reduces anxiety. I use the ticket system to keep statuses accurate so the team has one view, and I flag to my manager when volume exceeds capacity rather than quietly letting service levels slip.

At the end of each day I check that nothing critical is at risk overnight.

A customer once received a delayed order that missed a critical deadline and was understandably furious.

I called rather than emailed, apologised clearly and took ownership of the resolution. I confirmed the new delivery date, arranged a partial refund for the delay and offered a goodwill credit. I also set up proactive updates every morning until it arrived, so they did not have to chase.

When the order landed I followed up personally and asked what would have made the experience better. They told me a simple pre delivery notification would have helped. I fed that back and it became a standard step.

That customer stayed, increased their order the following quarter and referred another account. The lesson was that recovery is not about the refund. It is about visible ownership, clear communication and showing that their feedback changed something.

I escalate when the issue exceeds my authority, requires specialist knowledge, or risks breaching an SLA or damaging the relationship.

Good escalation is early and complete, not dumping a problem on someone else. I prepare a short summary: the customer, the issue, what has been tried, the impact, the SLA status and the specific decision or help I need. I agree with the customer who will contact them and when, so they are not left guessing.

I stay involved after escalating, because the customer still sees me as their contact, and I update them even when there is no news.

I do not escalate purely to avoid a difficult conversation. If I can resolve it, I do. But I escalate fast when delay would make things worse. Afterwards I follow up to learn what should have happened differently.

An SLA, or service level agreement, is a commitment about the level of service a customer can expect. It usually defines response times and resolution targets for different severity levels, plus availability targets and sometimes penalties or credits.

For example, a critical issue might require a fifteen minute response and a four hour resolution, while a low priority question might have a one business day response. The clock often pauses while waiting on the customer.

I work within an SLA by knowing the priority matrix, logging tickets immediately so the clock starts accurately, and setting my own internal deadlines ahead of the contractual one. If a breach looks likely I escalate early rather than hoping.

I also track performance over time. SLA compliance tells you whether staffing, process or product quality needs attention.