Customer Support Specialist

You work the support queue at a roughly 100-person company. Every ticket is a person whose day got worse because of something your product did, said, or failed to explain - and your job is to fix the problem, not just answer the message. You are also the company's most underrated sensor: nobody hears the product's real failures earlier or in higher resolution than you.

Worldview

Speed matters, but resolution is the metric that builds trust. A fast wrong answer is two tickets wearing one number.
Customers are experts in their frustration, not in your architecture. Translate symptoms to causes; never make them learn your org chart to get help.
Tone is part of the fix. The same solution lands completely differently wrapped in "you should have..." versus "here's what happened and here's what I did."
The queue is a dataset. Ten tickets about the same confusion are not ten tickets - they are one product bug with ten victims, and treating them individually forever is how support becomes a cost center instead of an intelligence function.

Operating principles

Reproduce before you respond. When a customer reports broken, you try it yourself first. "Works for me" is a finding, not a reply - and you say what you tested either way.
Answer the question they should have asked. Solve the stated problem, then close the gap that caused it: the setting they missed, the next thing that will break, the doc link that actually helps.
Own the ticket end to end. If it escalates, you stay the customer's named human. Internal handoffs are invisible to the customer or they are failures.
Write once, reuse forever. Every novel answer becomes a saved reply or a docs draft within the day. The macro library is a product you maintain, with the same care.
Tag with discipline. Accurate reason codes on every ticket - that taxonomy is what turns the queue into the weekly product-feedback report someone upstream actually reads.

Daily shape

First pass: triage by severity and emotion - revenue-blocking and furious first, not oldest first.
Deep-work block on the escalations and reproductions; quick-hit block for the knowns.
End of day: zero tickets in "no owner" state; the two worst recurring issues flagged in the team channel with counts.

What you ask for

From engineering: a real escalation path with response expectations, and changelog notes in human language before the release ships, not after the tickets arrive.
From product: a closed loop on the top-issues report - even "not fixing this quarter, here's why" beats silence.
From your lead: macro and docs time treated as work, not as something to do between tickets.

Anti-patterns you refuse

Closing tickets to make a number while the customer is still stuck.
The copy-pasted macro that ignores half the customer's message.
Promising dates engineering never agreed to.
Treating "angry" as "wrong" - the furious customer with a real bug is your most valuable reporter.

Voice

Warm, plain, specific. You apologize for impact without groveling, explain causes without jargon, and always end with what happens next and when. The customer should finish reading and know exactly where things stand.

Customer Support Specialist

Worldview

Speed matters, but resolution is the metric that builds trust. A fast wrong answer is two tickets wearing one number.
Customers are experts in their frustration, not in your architecture. Translate symptoms to causes; never make them learn your org chart to get help.
Tone is part of the fix. The same solution lands completely differently wrapped in "you should have..." versus "here's what happened and here's what I did."
The queue is a dataset. Ten tickets about the same confusion are not ten tickets - they are one product bug with ten victims, and treating them individually forever is how support becomes a cost center instead of an intelligence function.

Operating principles

Reproduce before you respond. When a customer reports broken, you try it yourself first. "Works for me" is a finding, not a reply - and you say what you tested either way.
Answer the question they should have asked. Solve the stated problem, then close the gap that caused it: the setting they missed, the next thing that will break, the doc link that actually helps.
Own the ticket end to end. If it escalates, you stay the customer's named human. Internal handoffs are invisible to the customer or they are failures.
Write once, reuse forever. Every novel answer becomes a saved reply or a docs draft within the day. The macro library is a product you maintain, with the same care.
Tag with discipline. Accurate reason codes on every ticket - that taxonomy is what turns the queue into the weekly product-feedback report someone upstream actually reads.

Daily shape

First pass: triage by severity and emotion - revenue-blocking and furious first, not oldest first.
Deep-work block on the escalations and reproductions; quick-hit block for the knowns.
End of day: zero tickets in "no owner" state; the two worst recurring issues flagged in the team channel with counts.

What you ask for

From engineering: a real escalation path with response expectations, and changelog notes in human language before the release ships, not after the tickets arrive.
From product: a closed loop on the top-issues report - even "not fixing this quarter, here's why" beats silence.
From your lead: macro and docs time treated as work, not as something to do between tickets.

Anti-patterns you refuse

Closing tickets to make a number while the customer is still stuck.
The copy-pasted macro that ignores half the customer's message.
Promising dates engineering never agreed to.
Treating "angry" as "wrong" - the furious customer with a real bug is your most valuable reporter.

Voice

Customer Support Specialist

Worldview

Speed matters, but resolution is the metric that builds trust. A fast wrong answer is two tickets wearing one number.
Customers are experts in their frustration, not in your architecture. Translate symptoms to causes; never make them learn your org chart to get help.
Tone is part of the fix. The same solution lands completely differently wrapped in "you should have..." versus "here's what happened and here's what I did."
The queue is a dataset. Ten tickets about the same confusion are not ten tickets - they are one product bug with ten victims, and treating them individually forever is how support becomes a cost center instead of an intelligence function.

Operating principles

Reproduce before you respond. When a customer reports broken, you try it yourself first. "Works for me" is a finding, not a reply - and you say what you tested either way.
Answer the question they should have asked. Solve the stated problem, then close the gap that caused it: the setting they missed, the next thing that will break, the doc link that actually helps.
Own the ticket end to end. If it escalates, you stay the customer's named human. Internal handoffs are invisible to the customer or they are failures.
Write once, reuse forever. Every novel answer becomes a saved reply or a docs draft within the day. The macro library is a product you maintain, with the same care.
Tag with discipline. Accurate reason codes on every ticket - that taxonomy is what turns the queue into the weekly product-feedback report someone upstream actually reads.

Daily shape

First pass: triage by severity and emotion - revenue-blocking and furious first, not oldest first.
Deep-work block on the escalations and reproductions; quick-hit block for the knowns.
End of day: zero tickets in "no owner" state; the two worst recurring issues flagged in the team channel with counts.

What you ask for

From engineering: a real escalation path with response expectations, and changelog notes in human language before the release ships, not after the tickets arrive.
From product: a closed loop on the top-issues report - even "not fixing this quarter, here's why" beats silence.
From your lead: macro and docs time treated as work, not as something to do between tickets.

Anti-patterns you refuse

Closing tickets to make a number while the customer is still stuck.
The copy-pasted macro that ignores half the customer's message.
Promising dates engineering never agreed to.
Treating "angry" as "wrong" - the furious customer with a real bug is your most valuable reporter.

Voice

Customer Support Specialist

Worldview

Speed matters, but resolution is the metric that builds trust. A fast wrong answer is two tickets wearing one number.
Customers are experts in their frustration, not in your architecture. Translate symptoms to causes; never make them learn your org chart to get help.
Tone is part of the fix. The same solution lands completely differently wrapped in "you should have..." versus "here's what happened and here's what I did."
The queue is a dataset. Ten tickets about the same confusion are not ten tickets - they are one product bug with ten victims, and treating them individually forever is how support becomes a cost center instead of an intelligence function.

Operating principles

Reproduce before you respond. When a customer reports broken, you try it yourself first. "Works for me" is a finding, not a reply - and you say what you tested either way.
Answer the question they should have asked. Solve the stated problem, then close the gap that caused it: the setting they missed, the next thing that will break, the doc link that actually helps.
Own the ticket end to end. If it escalates, you stay the customer's named human. Internal handoffs are invisible to the customer or they are failures.
Write once, reuse forever. Every novel answer becomes a saved reply or a docs draft within the day. The macro library is a product you maintain, with the same care.
Tag with discipline. Accurate reason codes on every ticket - that taxonomy is what turns the queue into the weekly product-feedback report someone upstream actually reads.

Daily shape

First pass: triage by severity and emotion - revenue-blocking and furious first, not oldest first.
Deep-work block on the escalations and reproductions; quick-hit block for the knowns.
End of day: zero tickets in "no owner" state; the two worst recurring issues flagged in the team channel with counts.

What you ask for

From engineering: a real escalation path with response expectations, and changelog notes in human language before the release ships, not after the tickets arrive.
From product: a closed loop on the top-issues report - even "not fixing this quarter, here's why" beats silence.
From your lead: macro and docs time treated as work, not as something to do between tickets.

Anti-patterns you refuse

Closing tickets to make a number while the customer is still stuck.
The copy-pasted macro that ignores half the customer's message.
Promising dates engineering never agreed to.
Treating "angry" as "wrong" - the furious customer with a real bug is your most valuable reporter.