Support Policy
Set SaaS Support Response Targets Without Promising Fix Dates
Separate first replies, progress updates, and fix forecasts into clear support targets your small SaaS team can staff, measure, and explain to customers.
Suppose a customer reports failed billing exports on Friday afternoon. Your team can acknowledge the report, but engineering has not reproduced the defect and cannot support a repair date. Set a first-response target the team controls and a separate time for the next update. Promise a fix date only after the fix owner has evidence and an agreed plan.
A support target is useful when everyone can identify what starts the clock, what stops it, which hours count, who owns the reply, and what happens when the target is missed. Small SaaS teams blur three commitments: first response, progress updates, and resolution. Define each promise and measure it on its own clock. Use workload evidence to choose targets the team can meet.
Give each customer promise its own clock
A first-response target measures how long a customer waits for a useful first reply. An update target measures the time between later progress messages while work continues. A resolution target measures how long the team expects to reach an outcome, such as a verified fix, a workaround, or a documented limitation. A service-level agreement (SLA) is a defined measure of the response and resolution times a support team provides. Support platforms model these commitments as distinct metrics. Zendesk, for example, documents first reply, next reply, periodic update, requester wait, agent work, and total resolution measures in its SLA policies. (Zendesk, “Defining SLA policies”)
A customer-support target is clear when it names five things: the event that starts the clock, the event that stops it, the hours included, the person responsible, and the action staff take when the target is at risk. Apply those five fields to every public promise and internal goal. A target such as “we reply quickly” names none of them. “A staff member acknowledges new weekday reports within one business day” defines a starting point, a kind of response, and a clock. The team still needs to specify holidays and monitored hours.
A first reply should answer a customer need as well as meet a timer. Decide whether “response” means any automated receipt or a human review that confirms the report is in the right queue. A receipt email can reassure the customer that a form submitted successfully. It cannot say whether staff understand the impact, need more information, or have routed the report correctly. If the team counts automatic messages toward its target, say so plainly and measure human review separately.
Set different targets for replies, updates, and outcomes
Use a short target card rather than one headline SLA:
| Promise | What it controls | Example wording |
|---|---|---|
| Acknowledgement | When a person will review and respond to the report | “We review new weekday reports within one business day.” |
| Progress update | How long a customer can expect to wait between meaningful updates | “If the investigation remains open, we will update you by the next agreed date.” |
| Resolution forecast | A forecast or contractual commitment for an outcome | “We expect to confirm the next release decision by Thursday.” |
These examples are policy patterns, with no universal recommended times. A support lead should choose values from the team’s coverage and work history. A fixed repair deadline belongs in a commitment only when the team has agreed to it and can manage the dependencies behind it. For an uncertain defect, a scheduled investigation update is usually more honest and more useful than an invented fix date.
Atlassian documents that Jira Service Management Cloud Premium and Enterprise administrators can show or hide configured response and resolution targets in the customer portal. A displayed target becomes an expectation a customer may plan around, so publish it only when staff can explain its meaning and exceptions. (Atlassian, “Support timelines in the portal”)
Choose business hours, calendar hours, and pause rules deliberately
A two-business-day promise and a 48-calendar-hour promise are different. Business-hour targets follow a staffed schedule; calendar-hour targets continue through nights, weekends, and holidays. Zendesk documents both kinds of SLA clock and allows business-hour schedules to pause outside configured operating hours. (Zendesk, “Defining SLA policies”)
Before publishing a target, write down:
- the time zone used for the customer-facing promise;
- the days and hours when staff monitor that channel;
- whether public holidays count;
- whether time waiting for customer information pauses a response or update clock;
- what happens when a customer replies after the team has closed the issue.
Pausing needs particular care. A team may pause a clock while it waits for a requested diagnostic detail, but only if the customer knows what to send and what will happen after they reply. Keep the clock running while engineering investigates. The customer is still waiting for the team’s next communication. Zendesk’s documentation illustrates how metrics may use different pause and restart rules; the important lesson is to define the rule per promise, then make sure reports use the same rule. (Zendesk, “Defining SLA policies”)
Set the first target from actual demand
A small team should not copy a large provider’s numbers. GOV.UK’s user-support guidance recommends estimating enquiries by channel and type, using historical handling time to plan staffing, and measuring response performance after launch. The manual was published on November 24, 2016; its capacity-planning method remains a practical way to test whether a proposed target matches available coverage. (GOV.UK, “Set up and manage user support”)
If you have recent support history, group reports by channel and reason. Estimate how many arrive in a staffed day, how long a useful acknowledgement takes, and how often a report needs engineering input before support can answer. If the team has no history, run a short measurement period before publishing a tight target. Use a cautious initial promise, then compare actual arrivals and response times against the staffed schedule.
GOV.UK defines a service level as the share of enquiries a team aims to solve within a set period. It recommends using historical demand and average handling time to choose the target. A target might therefore say “90% of weekday reports receive a human acknowledgement within one business day.” Use the percentage as a planning example, not as an industry benchmark. Choose the goal from your own data and publish the denominator, channel, and time window so the team can calculate it consistently. (GOV.UK, “Set up and manage user support”)
Do not let an average conceal the people who waited longest. Review the percentage meeting the target alongside missed cases and the oldest open reports. Split results by channel and issue type: a team may answer short account questions quickly while technical bug reports wait for a developer. That difference should change staffing or the promise, not disappear inside one blended number.
Route priority by customer impact and risk
Severity should reflect customer impact and risk. Message tone alone does not set urgency. A single user blocked from a time-critical task may need a faster human response than several people requesting a cosmetic improvement. A credible security or data-integrity report may need its own incident or security process and owner.
Write a small policy table before configuring targets:
| Case | First response | Resolution language |
|---|---|---|
| Routine question or low-impact defect | Within the normal staffed target | No fix date until the team has assessed the work |
| Customer blocked with no safe workaround | Faster acknowledgement and an explicit escalation owner | Promise the next decision or update time |
| Suspected security, privacy, or broad availability risk | Use the named security or incident route immediately | Follow that process and its own target |
| Customer waiting on a requested detail | Acknowledge receipt of the new detail within the normal reply target | Resume investigation and state the next checkpoint |
Keep the table small enough for the person receiving reports to apply without a meeting. If two rows lead to the same route and timing, combine them. If a target depends on a contract, check the contract before changing it.
Review misses as a policy test
Track three separate measures: first human response, later update intervals, and time to a recorded outcome. Also count target misses and customer messages asking whether anyone is handling the issue. A missed target can point to an ambitious goal, the wrong clock, an ownerless handoff, or an urgent case in the routine queue. Review the cause before changing the promise.
For product teams receiving reports by voice, a website widget, email, or a form, Mendaro’s shared issue intake is a strong fit when the operational problem is scattered customer reports that need to reach one issue workflow. Mendaro is an AI issue tracker for product teams and their customers; its homepage describes those intake channels and staff-reviewed Patchy Autopilot suggestions for triage. The team still sets its response policy, owns each reply, and decides what a fix forecast means. Teams that require contractual SLA enforcement, automatic deadline clocks, or public countdowns should verify those capabilities in a dedicated support platform.
A workable policy can fit on one page. Name each promise, define its clock and exception rules, assign a person to watch it, and review the misses. Customers can distinguish “we have your report,” “we are investigating,” and “we expect a fix.” The product team can then keep its acknowledgement target within its control.
