To set customer service goals, choose a customer problem, record a baseline, and write a measurable outcome with an owner and review date. Confirm that your team can do the work, test a small change, and check answer quality alongside the main measure.
For an online store, the starting point might be repeated delivery questions or inconsistent return instructions. This guide explains how to set customer service goals with a hypothetical delivery-support example. The numbers illustrate how to write a goal; they are not recommended benchmarks. If you still need to choose an outcome, read the customer service goal examples first. For formulas and counting rules, use the target measurement guide.
Step 1: Choose one customer problem
Read recent conversations and ask the team where customers get stuck. Include unresolved requests, escalations, and negative feedback. Closed conversations alone can give you a selective view of the queue.
Describe the problem in terms a customer would recognize. “Customers with delayed parcels ask again because our first reply gives no follow-up date” is specific enough to investigate. “Improve service” leaves the team to guess what work matters.
Check the business priority behind the problem. If your store is preparing for a promotion, reliable delivery communication may matter more than expanding support channels. If customers receive conflicting return advice, address that before adding another response-time goal. The objectives guide helps with those choices.
Separate symptoms from causes. Support can promise a useful update, but it cannot guarantee a carrier’s delivery date. Give fulfillment ownership of the operational issue and keep the support goal within the team’s control.
Write a short problem statement before you discuss a number. Agree on whose experience should improve, which cases are involved, and what a better outcome would look like.
Step 2: Record the baseline and reporting rules
Measure the current workflow before changing it. Use a period with enough relevant cases to see the problem, and note promotions, staffing gaps, or delivery incidents that affect the result.
For the worked example, suppose a store reviews 100 delayed-delivery cases. Thirty customers contacted the team again about the same unresolved delivery question within seven days. That is a hypothetical baseline of 30 repeat-contact cases out of 100 eligible cases.
Keep a record of what counted. Did you include only email? Did a customer’s reply with requested information count as a repeat question? How did you recognize two messages about the same order? These choices affect the result.
Agree on the rule before comparing periods. For this example, count a repeat only when the customer asks again for an update on the same delivery issue. Exclude requested evidence and unrelated questions. Give each case its full seven-day observation period.
If the team has no reliable reporting yet, make baseline collection the first task. You can review a small case sample manually. Explain which cases you reviewed and what the sample leaves out.
Step 3: Write the goal using SMART
SMART is a check on the plan: specific, measurable, achievable, relevant, and time-bound. It helps expose missing decisions before the team starts. It does not tell you which number is appropriate for your store.
Make the outcome specific and measurable
Name the customer problem and the affected work. In the delivery example, the outcome is fewer repeat requests for an update after the first support reply. It applies to delayed-delivery email cases, rather than every conversation in every channel.
Use the baseline rule to define the measure. Record both the count of repeat cases and the total eligible cases. The target guide explains denominators and observation windows in more detail.
Add a quality check: the first reply must give verified order information, the next action, and a follow-up date the team can meet. This prevents an apparent improvement caused by discouraging customers from contacting you.
Check that the work is achievable and relevant
Ask agents to inspect the proposed change. Do they have access to current order details? Who can answer a carrier escalation? Can the team send the promised follow-ups during its staffed hours?
A target becomes a guess when the team lacks those resources. Start with a limited trial and explain what you expect it to teach you. The customer problem should also connect to an agreed store priority, such as reliable communication during delivery delays.
Set a deadline for the decision
Choose a start date and a decision date. Leave enough time after the trial for every included case to complete its observation window. Otherwise newer cases have less opportunity to generate a repeat contact.
A hypothetical goal could read: “For delayed-delivery email cases opened during November, reduce repeat-update requests from the baseline 30% to 25%, using the same seven-day rule. Review the result on 10 December. The support lead owns the trial and checks first replies for accurate information and a promised follow-up.”
Those figures and dates illustrate a complete statement. Your own baseline, capacity, and customer commitments should determine your plan.
Step 4: Assign an owner and secure the resources
Give one person responsibility for coordinating the work and bringing the result to review. That person needs a way to resolve blocked decisions; they do not need to handle every case personally.
List the people who own dependencies. In the delivery example, fulfillment provides a route for parcel investigations. The support lead owns the reply guidance and follow-up process. Agents need to know whom to contact when tracking and the customer’s account disagree.
Check the time required. Reviewing cases, editing instructions, and testing a new reply all take capacity away from the live queue. Agree on what can wait while the trial runs. Training time should appear in the plan rather than become unpaid work after a shift.
Confirm any spending before the team depends on it. If the change needs order access or another inbox, check the software plan and permissions. Use the help-desk cost calculator to compare staffing needs with plan costs, then verify the relevant pricing details.
Step 5: Write a brief the team can use
Keep the goal in one shared record. A short brief should let an agent understand the change without finding the original planning conversation.
| Field | Hypothetical delivery-support goal |
|---|---|
| Customer problem | Customers ask again because the first update gives no next step |
| Scope | Delayed-delivery email cases opened during November |
| Baseline and target | 30 repeat-contact cases per 100 eligible cases; trial target 25% |
| Counting rule | Same delivery issue within seven days; exclude requested evidence |
| Workflow change | Check order state, explain next action, record a follow-up date |
| Owner and dependency | Support lead; fulfillment contact for parcel investigations |
| Quality check | Review first replies for accuracy and a follow-up the team can meet |
| Decision date | 10 December, after all included cases complete the observation window |
Explain the change in a team discussion before you start. Ask an agent to work through an ordinary case and an exception. If two people interpret the rule differently, correct the brief then.
Keep the current version of reply guidance beside the brief. A customer service policy should identify who can approve an exception. The goal should not silently change your delivery or refund promises.
Record decisions in writing so staff on another shift receive the same information. A meeting is useful for questions, but it is not a durable record for someone covering the queue next week.
Step 6: Test the change on a limited set of cases
Start with the cases named in the brief. Avoid changing the reply process, staffing schedule, help center, and survey at the same time if you want to understand which change helped.
For the delivery example, agents use revised reply guidance and record a follow-up date. The lead checks early cases to see whether agents can obtain the promised information. If fulfillment cannot provide it, resolve that dependency before expanding the trial.
Use saved replies for stable wording, with agents checking order-specific details. If you use automation to route cases, inspect exceptions and confirm that someone owns them. Check the routed conversation to see whether the customer received a useful answer.
Keep a brief change log. Note when guidance changed, which cases it affected, and any disruption during the trial. Without that context, a difference in the final result can be hard to interpret.
A limited trial can reveal practical problems. It is not automatically evidence that the same result will hold through a peak season or a different mix of requests.
Step 7: Review results and decide what happens next
Use a brief weekly check to find blocked work and missed follow-ups. Save the larger decision for the agreed review date, when the included cases have had time to reach an outcome.
Compare the result with the original baseline and target. Suppose the hypothetical trial ends with 26 repeat-contact cases out of 100 eligible cases. That is below the baseline but above the 25% target. Report both facts. Do not rename 26% as the target to make the trial appear successful.
Read a sample of cases, including ones that failed the quality check. Review customer feedback for issues the main measure missed. A lower repeat-contact rate is less convincing if unresolved complaints increased.
Decide whether to continue, revise, or stop the change. A revised plan should state what changed and why. Preserve the original brief, the result, and the decision so the next review has a reliable starting point.
If volume was too low or a major incident changed the case mix, say that the result is inconclusive. Extend observation or run another limited trial rather than claim a lasting improvement from weak evidence.
Avoid goals that reward the wrong work
Check what an agent would do if they tried to improve only the headline number. A response-time target can encourage empty acknowledgments. A closure target can encourage closing difficult cases too soon. A cost target can discourage necessary investigations.
Use a quality check that matches the risk. For speed, inspect whether replies answer the question. For closure, inspect reopened and unresolved cases. Explain how those checks affect the review so the team can use judgment when a customer needs extra time.
Separate team outcomes from individual development. Agents who handle refund exceptions will not have the same case volume as agents answering routine delivery questions. Review the work assigned before comparing their totals. Individual coaching can focus on a specific skill, such as checking order state before using a saved reply.
Keep the plan close to the work in ThriveDesk
ThriveDesk can give the team a shared record for the workflow you are changing. Use the shared inbox for assignment and internal notes, then review the actual conversations behind the result. Keep the goal brief in your team’s planning record; an inbox does not replace the written decision about scope and counting rules.
For a store using WooCommerce, customer and order context can help agents check the case before replying. Pair that access with saved replies for routine instructions and a clear escalation route for exceptions. The trial should test whether the team can use those tools under its ordinary workload.
ThriveDesk’s reporting features provide a starting point for service reviews. Check the definitions available in your account before treating a report as the custom measure in your brief. A repeat-contact rule may require a separate case review or export.
Basic is $29 per month on monthly billing for 2 teammates and 1 inbox. Larger teams should check the current plan limits before they budget for a rollout. Include the time needed for setup and review alongside the subscription cost.
Start with the workflow your goal requires. You can add more automation after the team has checked the rule and knows how to handle a case that falls outside it.
