Make service timing targets clear enough to act on

WorkOrderPro product guide · Updated 12 September 2026.

What SLA tracking should help a service team decide

SLA tracking compares recorded service events with a defined time target. For a field service business, it can help the office recognise work that has exceeded an agreed operating threshold and decide what needs attention. The useful outcome is an informed response: somebody understands the delayed work, reviews the customer situation and takes responsibility for the next step.

WorkOrderPro supports priority-based rules with response hours, resolution hours and a business-hours-only option. Its calculations use work-order timestamps and status history, including recorded hold periods. These are specific measurement definitions. Before applying them to a customer agreement, confirm that the definitions match the service promise you intend to monitor.

An SLA record is not a guarantee that a technician will arrive or that a repair will be completed within the target. It does not decide contractual penalties or certify compliance with every customer agreement. It provides an operational comparison based on the configured rule and the saved work record. Good configuration and accurate status updates make that comparison more useful.

Define the promise before choosing the numbers

Start with a plain-language description of the service commitment. Decide what starts the measurement, what event counts as a response and what counts as resolution. A telephone acknowledgement, a technician being dispatched and physical arrival are different events. Calling all three “response” without choosing one creates confusion even when the software calculates elapsed time correctly.

For resolution, establish whether the measure concerns the original agreed scope, restoration of a service or some other outcome in the customer arrangement. The system's recorded completion event needs to be understood in that context. A technician leaving the site is not automatically the same as the work being resolved.

Write one worked example before setting the rule. Include the request time, the relevant status transitions and the result you expect. Ask dispatch and the account owner to explain the calculation independently. If they produce different answers, resolve the definition before relying on a dashboard or breach alert. A shared interpretation is the foundation of useful service reporting.

Understand WorkOrderPro's response measurement

The current response calculation starts from the work order's creation timestamp and ends at the first recorded transition to on-site status. While that transition has not happened, the calculation measures toward the current time. This definition is useful to understand because it measures the recorded arrival stage, rather than an email reply or an initial telephone conversation.

Keep the creation event consistent with the process you want to assess. If incoming requests sit outside the system for a long time before an employee creates a work order, the measured interval will not include that earlier waiting period. The resulting number can still be correct for its definition while failing to answer the broader customer-response question.

Train the team to use the on-site transition at the appropriate point in the actual workflow. Late status updates can distort the recorded response interval. Do not change statuses merely to improve a target result. A useful measure should reflect the work honestly and make delays understandable, including delays caused by the office process itself.

Understand WorkOrderPro's resolution measurement

The resolution calculation also begins with work-order creation. For work with an actual completion time, that timestamp provides the endpoint; otherwise the calculation runs toward the current time. Recorded hold periods are subtracted under the service's effective-time calculation. This means response and resolution share a starting event but answer different questions about the job's progress.

Review the meaning of completion with the team. The agreed scope may be finished while a separate recommended task remains for customer consideration. Alternatively, the visit may have ended with the original problem unresolved. The work record should explain that difference so a reader does not infer resolution from a convenient status label.

When reviewing a resolution exception, inspect the underlying sequence. Was the assessment completed promptly but approval delayed? Did a required part affect progress? Was access unavailable? A total duration identifies a timing result; the work notes and status history explain the operational story. Both are needed before deciding how to improve the service process.

Configure priorities consistently

WorkOrderPro's SLA rules match work-order priority within the business. Supported priorities are low, normal, urgent and emergency. Choose a rule for the priority you intend to monitor and ensure the team understands how that priority is assigned. A request labelled emergency should represent a meaningful operating distinction, not simply the preference of the last person who spoke to the customer.

Create a short triage guide with examples relevant to your trade. The guide should explain who can classify or change priority and how unusual cases are escalated. Technical safety decisions remain with appropriately qualified people and the relevant emergency procedures. Software priority is an operating classification, not an independent assessment of risk.

Review priority changes as part of the job story. A rule lookup uses the work order's current priority, so the team should understand the effect of changing that field. Avoid treating a priority change as an informal way to make an inconvenient timer disappear. The record should support an honest explanation of the work and its handling.

Distinguish business hours from calendar time

A calendar-time rule measures elapsed time across the whole period, subject to the recorded hold calculation. A business-hours rule counts the configured operating windows. These can produce very different results for a request created near closing time or before a weekend. The customer and office need to understand which convention applies to the service arrangement.

WorkOrderPro reads the tenant's operating-hours setting for the business-hours calculation and uses a default schedule when an appropriate setting is absent. Review the actual configured hours during setup instead of assuming that they match your office's working pattern. The calculation uses South African local time for these operating windows.

Review weekends and exceptional closure assumptions

A weekly operating schedule does not automatically establish a complete holiday or exceptional-closure calendar. During your trial, test the periods that matter to your business and inspect the actual result. If your agreement excludes public holidays or uses a special shutdown arrangement, confirm how that requirement is handled before promising an exact match.

Do not assume that every customer shares the same operating-hours expectations. A commercial site with continuous operations may interpret an urgent response differently from a customer whose work is only arranged during office hours. The current priority-based rule structure should be evaluated against those real differences in your customer portfolio.

Use explicit examples in the internal operating guide. A Friday afternoon request and a Saturday request can reveal assumptions that a Tuesday morning demonstration never exposes. The purpose is to make the measurement predictable to the people relying on it. Where the agreement needs a rule the current setup does not represent, identify the separate review process instead of disguising the mismatch.

Use hold status with a clear operational reason

The current SLA service subtracts periods recorded as on hold from effective elapsed time, including when the rule uses calendar time. Hold periods come from the status-transition history. This makes the way the team uses hold status a significant part of the measurement, rather than merely a visual label on the dispatch queue.

Define the circumstances in which work may be placed on hold and who reviews that decision. An external dependency may be relevant to your operating process, but the customer agreement may define exclusions differently. Do not assume that the software's subtraction automatically establishes a contractual right to pause the service obligation.

Record the actual reason and next action in understandable language. Someone should know what will release the job and when to review it. A job left on hold without ownership can become invisible to ordinary urgency even though the customer still needs help. The pause should explain the process, not remove the work from responsibility.

Read a breach as a prompt to investigate

A recorded breach indicates that the calculated effective time reached or exceeded the configured threshold for the measured type. WorkOrderPro distinguishes response and resolution breaches. The service avoids creating another breach record for the same job, rule and type once one exists. This helps preserve a recognisable event rather than filling the record with repeated copies of the same detection.

Begin the review with the current customer situation. Determine whether attendance or resolution still needs action, then inspect the event history and configured rule. A historical breach may remain relevant even after the team has completed the work. Conversely, a newly detected exception may require immediate operational attention from the dispatcher or account owner.

Do not infer the cause from the breach label alone. It might involve late data entry, an unsuitable rule, missing access or a genuine service delay. Establish the facts before discussing accountability or a customer remedy. A timing exception becomes useful management information when it leads to an accurate explanation and a practical next action.

Separate detection, notification and response

The application includes a scheduled breach-checking command and a dispatcher notification path. The scheduler is configured to run the check at five-minute intervals. That is periodic evaluation, not a promise of an instantaneous live alert at the exact threshold. Operational availability and configured message delivery still need verification in the deployed environment.

A breach record, an attempted notification and an employee taking action are separate events. Demonstrate all parts you intend to rely on during setup. Confirm who receives the notification, how the team recognises it and which person acts when the usual dispatcher is unavailable. An alert with no clear owner can remain unattended even when every technical delivery step succeeds.

Keep an ordinary review routine alongside notifications. The office should be able to inspect the service queue and identify unresolved work without relying on one inbox. This is especially useful during handovers, absences or a communication issue. The software can draw attention to an exception; the business remains responsible for arranging the response.

Review the whole job before explaining a result

When discussing a timing result with a customer or manager, bring together the job reference, creation time, relevant transitions, hold context and completion information. Explain the measurement definition in plain language. A number labelled response hours is easy to misunderstand if the reader assumes it means the first telephone acknowledgement while the system measures arrival.

Use the review to distinguish record quality from service performance. Both can need improvement, but they require different actions. A technician who arrived promptly and updated the status late needs a better recording habit. A genuine dispatch delay may require capacity or preparation changes. Treating both as the same problem prevents an effective response.

Keep SLA measures separate from labour and billing

An SLA interval is not a technician's worked-hours total. It can include time before assignment, waiting for a decision and other parts of the job lifecycle. Time tracking records individual working intervals for a different purpose. Comparing those records can add context, but they should not be substituted for one another.

Likewise, a breach does not automatically calculate a customer credit, penalty or invoice adjustment. Those outcomes depend on the actual agreement and the reviewed commercial process. The responsible person should interpret the evidence and handle any customer discussion through the appropriate procedure.

Make these boundaries clear in reporting. A service manager looking at resolution performance needs the rule definition and job context. An accounts reviewer needs the accepted charging basis. A crew planner needs labour and attendance information. Each can use the work record, but each is asking a different question. Clear measures help the team make better decisions without overextending what one timer proves.

Run a controlled SLA acceptance exercise

Choose a small set of sample jobs with known event times and priorities. Include one that reaches on site within the response target, one that exceeds it and one with a recorded hold period. Compare the expected effective duration with the saved calculation. Test business-hours behaviour near a closing boundary rather than only during the middle of the working day.

Include the operational handover after a detected breach. The dispatcher should identify the job, inspect the current state and explain the next action. If notifications are part of the chosen process, verify the actual delivery path and recipient. Use controlled sample information so the exercise does not confuse a real customer or create a misleading service promise.

Record any mismatch precisely. Was the rule wrong, the status event missing or the expectation based on a different definition? This gives the team a concrete setup decision. A successful trial demonstrates both the calculation and the human response, because either part can undermine the usefulness of the overall process.

Use timing evidence to improve the service operation

After the rules and recording habits are stable, review patterns across comparable work. Separate priority groups and distinguish response from resolution. Read a sample of underlying jobs before deciding that one broad average explains the business. A repeated access problem calls for a different intervention from delays caused by poor assignment or unclear proposal approval.

Choose one operational improvement and observe later comparable work. You might strengthen request capture, clarify hold ownership or improve the handover from assessment to quotation. Avoid claiming a guaranteed reduction in delays from a small sample. The defensible result is a clearer process and evidence that the specific change helped under the conditions observed.

Confirm SLA-tracking availability in current pricing. Staff billing includes active administrators, dispatchers and field users, excluding disabled accounts. Start a trial with service rules your team can explain, then use the resulting records to evaluate whether the system supports your actual response and resolution responsibilities.

Make rule ownership part of the operating routine

Assign responsibility for reviewing SLA settings when the service offering or operating hours change. The person editing a threshold should understand which work it affects and how the team will interpret later results. Keep the reason for a change in your normal operating documentation so a future reviewer can distinguish a changed target from a change in service performance.

Train a backup reviewer to explain a sample response and resolution result. They should understand the creation event, on-site endpoint, completion time and hold treatment without depending on the original administrator. This makes the process more resilient during leave or staff changes. A small set of worked examples is often more useful than a long general policy because it shows exactly how the rule behaves in an ordinary visit and a realistic exception.