FieldproxyAI-native field service software

Contracts and SLAs

How do I track SLA response and fix times on field jobs and escalate before a breach?

Give every job a priority, and let the priority and the customer's contract set two deadlines: respond by (an engineer on site, or a first contact) and fix by (the fault resolved). Start both clocks when the request is logged, count only the contract's hours, pause the clock only for reasons the contract allows (customer not ready, no access, parts on order if agreed), and send a warning before each deadline, not after it. Escalate in steps: the engineer and dispatcher at the warning, a manager at the breach, and leadership for anything still open past a set age, such as two days.

  • Two clocks per job: response (on site or first contact) and fix (resolved), each set by priority and contract.
  • The arrival is only proven by a check-in on site, so the check-in method decides your SLA numbers.
  • Pause rules belong in the contract; every pause needs a reason code and a timestamp.
  • Warn at a set share of the time (for example half or three quarters), escalate at the breach.
  • Engineers need the deadline on the phone, sorted by time left, not just a priority label.

Book your demo

60 minute video call ยท Step 1 of 2: your details, then pick a time

Number of employees

This page is about SLAs on field visits. If your SLA is only about how fast a help desk replies to an email, your help desk's own SLA policies already cover it.

Facts checked as of November 2026. Sources at the end of the page.

Step by step

How SLA tracking on field jobs works, step by step

The records are the same whether the job comes from a phone call, a portal, a help desk ticket or a client's work order system.

1. Write the SLA matrix down

One row per priority per contract: for example P1 emergency, respond in 4 hours and fix in 24; P2 urgent, respond next business day and fix in 3 days; P3 routine, schedule within 10 business days. Add the hours that count (24/7 or business hours, and whose time zone) and the allowed pause reasons. If it is not written down, every breach becomes an argument.

2. Set priority and contract when the job is created

The job inherits the customer's contract and its matrix. Priority comes from the caller, the ticket or the client's work order. Clients who send work through a portal such as ServiceChannel include the required SLA and the not-to-exceed amount on the work order itself, so the job should carry those values, not retype them.

3. Stamp two deadlines on the job

Respond-by and fix-by are calculated once, from the created time, and stored on the job. Dynamics 365 Field Service works this way: an SLA KPI such as Work Order Arrival Time is measured from a field you choose (Created On, for example), with a warning duration and a failure duration, calculated in the SLA's business hours.

4. Stop the response clock with a real check-in

Arrival is proven by the engineer checking in on site, by app with GPS or by phone. On ServiceChannel, emergency SLA compliance counts only work orders that have a check-in, so a forgotten check-in reads as a miss even when the engineer was early.

5. Pause only with a reason

When the job is waiting on the customer (no access, site closed, customer asked to rebook) the fix clock pauses and the reason is logged. Dynamics 365 has an optional Allow Pause and Resume setting so the SLA pauses while the record is on hold. Waiting on parts is a contract decision: many maintenance contracts do not let you stop the clock for your own stock.

6. Warn before the deadline

At the warning point (say 50% or 75% of the time used) the engineer, dispatcher and supervisor get an alert. Salesforce Field Service does this with an entitlement process on work orders: milestones such as a 48 hour resolution time for critical and high priority work orders, with time-based actions. A process built for cases does not run on work orders; they need their own.

7. Escalate at the breach and by age

At the breach the manager gets the job, with who has it, where they are and why it is late. A second rule catches slow drift: anything open longer than a set age (for example two days) goes to leadership, whatever its priority. Zoho Desk's escalations, for example, send overdue tickets to the relevant manager or agent automatically.

8. Close with the times on the report

The service report and the monthly SLA report both read the same timestamps: created, arrived, paused and resumed, fixed. Measure respond and fix separately, per priority and per customer, and keep the pause log with them so the customer can see why a clock stopped.

Where it breaks

Why SLA tracking goes wrong

These are the problems buyers described on our sales calls: EV charger maintenance, robotics service under annual maintenance contracts, lift maintenance across retail sites, telecom tower inspection and field installation.

Engineers see a list, not a deadline

An EV charger maintenance team worried that engineers would scroll their assigned jobs without knowing what to do first. A priority label does not say the P2 job has 40 minutes left and the P1 has six hours. Sort by time remaining and show it on the phone.

The SLA lives in the help desk, the work happens in the field app

The ticket has the priority and the clock; the field job does not. When the engineer closes the job, nobody updates the ticket's SLA, or the ticket closes on time while the fault is still there. The priority and deadlines must travel with the job and the resolution must travel back.

Dead time is invisible

A robotics manufacturer with about 26 engineers wanted to see dead time: hours where nothing happens because a part, an approval or a customer reply is pending. Without pause reasons, the report shows a breach and nobody can say whose wait it was.

Old tickets fall out of view

The same team asked for anything older than two days to go to leadership automatically. Routine jobs with soft deadlines never trip a breach alert, so they sit for weeks unless age itself triggers an escalation.

The clock is reset by accident

If the start of the clock is tied to the last time the record changed, every note, reassignment or status edit restarts it, and the job never looks late. The start point should be a fixed timestamp, usually when the request was logged. In Dynamics 365 this is the Applicable From setting on the SLA KPI, where Created On measures from creation.

The report SLA is forgotten

A tower inspection firm had a 24 to 48 hour SLA on the report after the visit, not just the visit itself. If the report is a separate deadline, it needs its own clock that starts at check-out.

The options

Ways to track SLAs on field jobs

ApproachResponse and fix clocksPause and escalationNote
Spreadsheet plus emailTyped in by the officeBy handBreaks above a handful of jobs a day; no proof of arrival
Help desk SLA policies (Zendesk)First reply, next reply, periodic and pausable update, resolution time; business or calendar hoursPausable update stops while the ticket is PendingMeasures agent replies on the ticket, not the engineer's arrival
Help desk escalations (Zoho Desk)SLA per ticketOverdue tickets escalate to a manager or agent; views of SLA-violated ticketsNeeds a field app beside it for check-in and the visit
Dynamics 365 Field ServiceSLA KPIs such as Work Order Arrival Time and Work Order Resolution, in business hoursOptional pause while on hold; warning and failure durationsStrong but configured by an admin or partner
Salesforce Field ServiceEntitlement processes with milestones on work ordersTime-based actions and a milestone trackerWork orders need their own entitlement process
FieldproxyRespond-by and fix-by on the job from priority and contract (set up for you)Watcher agent flags jobs heading for a breach; escalation rules by age and priorityAsk to see your own matrix built in the demo

As of November 2026, from each vendor's own documentation (sources below). Plan levels and setup effort vary; check what your edition includes.

Worked example

A worked example: one P1 and one P2 on the same morning

Say a maintenance contractor has a contract with a retail chain: P1 respond on site in 4 hours and fix in 24, P2 respond next business day and fix in 3 business days, both measured in 24/7 hours for P1 and 8:00 to 18:00 weekdays for P2. Warning at 75%. Made-up numbers to show the flow, not results.

At 9:00 a P1 comes in: a store's refrigeration alarm. Respond-by is 13:00, fix-by is 9:00 tomorrow. The warning fires at 12:00 if nobody has checked in. At 9:15 a P2 arrives: a door closer. Respond-by is 18:00 the next business day, fix-by three business days later.

The engineer's app now shows the P1 first with 3 hours 45 minutes left, then the P2 with 32 business hours left. The engineer checks in at the store at 11:40: the response clock stops at 2 hours 40 minutes, inside target.

The fault needs a compressor part. The contract does not allow a pause for parts, so the fix clock keeps running. The part arrives at 17:00, the engineer is back at 18:30, and the alarm is cleared at 20:10. Fix time: 11 hours 10 minutes, inside the 24 hours.

The P2 is different. When the engineer arrives the next morning, the store has no keyholder until the afternoon. The engineer marks the job paused, reason 'no access', at 10:05; it resumes at 14:00. Those 3 hours 55 minutes come off the clock and appear on the customer's SLA report with the reason, which is what stops the end-of-month dispute.

Before you buy

What to check before you buy

Good signs

  • Separate respond-by and fix-by deadlines per priority and per contract, stored on the job.
  • Business hours and time zones per contract, not one setting for the whole company.
  • Pause and resume with a reason code, visible on the job and in the report.
  • The engineer's app sorts by time left and shows the deadline, not only a priority color.
  • A warning before the breach, an escalation at the breach, and an age rule for old jobs.
  • Priority and deadlines come in from your help desk or client portal and the resolution goes back.

Red flags

  • The SLA exists only as a report you run after the month ends.
  • The clock is measured from the last edit, so any update resets it.
  • Arrival is typed in by the office instead of a check-in on site.
  • Pauses are allowed with no reason and no audit trail.
  • The demo shows one generic SLA instead of your contract's matrix.

In Fieldproxy

Setting it up in Fieldproxy

Fieldproxy is set up around your own stages, fields and rules, so the SLA matrix is built from your contracts rather than picked from a template.

Contracts carry the matrix

Each customer contract holds its priorities, respond and fix targets, hours that count and allowed pause reasons (e.g. P1 4h/24h, 24/7). Recurring maintenance visits are generated from the same contract (see /solutions/recurring-jobs).

Jobs get two deadlines

When a job is created from a call, the customer portal, an email or a help desk ticket, it takes the contract and priority and stores respond-by and fix-by (e.g. as two date fields on the job). Tickets from Zendesk, Freshservice or Zoho Desk can become jobs, with notes and the resolution written back (see /solutions/helpdesk-to-field-dispatch); ask us to map your ticket's priority and SLA fields in the demo.

Check-in stops the response clock

Engineers check in on site from the Android or iOS app with GPS, and statuses such as on hold carry a required reason, so pauses are logged with who, when and why.

The Watcher agent warns and escalates

The Watcher agent (/agents/watcher-agent) watches open jobs against their deadlines and flags the ones heading for a breach, with escalation steps you choose (e.g. engineer and dispatcher at 75%, operations manager at breach, leadership for anything open over two days).

The right engineer for a tight deadline

The Dispatch agent (/agents/dispatch-agent) suggests who can reach the site in time by distance and skills, and the Scheduler agent (/agents/scheduler-agent) can email a morning list of jobs at risk and a monthly SLA summary per customer.

Reports per customer

Response and fix times per priority, breaches with reasons and pause logs come from the same timestamps (see /solutions/dashboarding-reporting). Pricing is one price per company with unlimited users; see /pricing.

By region

Regional notes

US facilities work: many retail and restaurant clients issue work through portals such as ServiceChannel, which score providers on check-ins. ServiceChannel's provider guide sets an emergency SLA compliance goal of 62% and a check-in compliance goal of 90%, and only GPS or IVR check-ins count for PM compliance, so the check-in habit decides your scorecard.

UK, Ireland, Australia and New Zealand: maintenance contracts usually state response and attendance times per priority and whether they run on working hours or around the clock. Check whether bank or public holidays count, and set them per region if you work across borders.

How switching works

How switching to Fieldproxy works

We move your data over and set the system up to the way you already work. Fieldproxy replaces the old tool; it does not run alongside it.

  1. Bring your contracts

    Send us the SLA schedule from two or three real contracts, plus how jobs reach you today (calls, portals, a help desk).
  2. We build your matrix

    Priorities, respond and fix targets, hours, pause reasons and escalation steps are set up on your contracts and jobs.
  3. Run a live P1 in the demo

    Raise a test emergency, check in from a phone, pause it with a reason and watch the warning and escalation fire.
  4. Go live and report

    Engineers get the app, dispatch sees jobs by time left, and customers get SLA reports from the same timestamps.

FAQ

Questions people ask

What is the difference between response time and fix time?
Response time runs from when the request is logged to when an engineer is on site (or makes first contact, if the contract says so). Fix time runs from the same start to when the fault is resolved. Track them as two clocks with two deadlines.
Does the priority and SLA from our help desk ticket flow through to the field job?
It should. The job needs the ticket's priority and deadlines when it is created, and the ticket needs the arrival and resolution times back. Check that the link works in both directions before you buy.
Can the engineer app alert for high-priority jobs or an SLA breach?
Yes in tools built for it: the job shows its deadline, the list sorts by time left, and a warning goes to the engineer and dispatcher before the breach.
Can we pause the SLA when the customer is not ready?
Yes, if the contract allows it. Log the reason and the times, so the pause shows on the customer's report. Dynamics 365, for example, can pause an SLA while the work order is on hold.
Can tickets older than two days escalate to leadership automatically?
Yes. Add an age rule beside the breach rule, so jobs with soft or no deadlines still surface. Zoho Desk and most field tools can do this with an automation.
Should parts delays stop the SLA clock?
Only if the contract says so. Many maintenance contracts treat your own stock as your problem. If you can pause for parts, record it as a separate reason so it can be reported.
How do we show the customer we met the SLA?
Send a monthly report per priority with created, arrived, paused, resumed and fixed times, and the reason for every pause and breach.

Sources

Competitor details on this page come from the vendors' own pages and documentation, checked as of November 2026. Plans and prices change, so check the vendor's current page before you decide.

See it built on your workflow

Tell us how your jobs run today. We build a demo on your stages, forms and pricing before the call.