A customer logs an urgent issue. Before an engineer attends, the FM provider may need to identify the right contract, confirm the service scope, determine priority, establish the relevant commitment, check access and decide who can realistically take the work.
That is why SLA management starts before an engineer arrives.
An SLA is not simply a result recorded when a job closes. In facilities management, it is an agreed service standard that acts as both a contractual commitment and an operational guide.1 The report at the end of the month may show whether the target was met. But by then, the outcome is fixed.
The real management question is different:
Which live jobs are approaching risk, what is causing that risk, and what can the team still change?
For an FM business with several contracts, different priorities and a busy field team, that question cannot be answered from a spreadsheet after the event. The relevant commitment, remaining time, work status and next decision need to be visible while the job is still open.
The relevant SLA starts where the contract says it starts
The phrase “SLA clock” is useful, but it can hide important contract detail.
For one customer, the relevant time may begin when a request is logged. For another, it may begin after validation, classification, an agreed working-hours calculation or another stated condition. Some agreements will define pause conditions. Some will distinguish emergency work from routine work. Some will specify attendance, while others focus on a defined first action, restoration or full resolution.
The operational principle is simple: the business must know the applicable requirement early enough to act on it.
That means a service request should not sit as an unclassified item in an inbox while the team decides who owns it. The contract manager, helpdesk or scheduler needs a clear view of the service scope, priority, target and conditions that apply to that specific job.
Macro’s FM guidance describes an SLA as the agreed benchmark for service performance, including scope, response times, resolution times and quality thresholds.1 The exact targets will differ by service, site, risk and contract. The need to make them visible at the start of the job does not.
An SLA-controlled job has a lifecycle, not one deadline
A job with an SLA is not managed through a single timestamp. It moves through a chain of decisions.
- A service request is received.
- The business identifies the relevant customer, contract and service scope.
- The request is classified and prioritised.
- The appropriate response and, where relevant, resolution commitment is made visible.
- The work is allocated to an appropriately skilled resource.
- The engineer accepts, attends or carries out the required first action.
- The team manages any follow-on work, access issue, parts requirement or specialist involvement.
- A manager escalates if the job is at risk.
- The work is completed, evidenced and communicated to the customer.
- Performance is reviewed against the agreed requirement.
Any weak point in that sequence can reduce the business’s ability to meet the commitment. A job might be sent to the wrong team. It may be given the wrong priority. The engineer selected may not have the necessary competency. Access may not be available. A reactive request may arrive when every suitable person is already committed elsewhere.
This is why SLA performance is not principally an engineer-performance issue. It is an information, prioritisation, allocation and visibility issue across the operation.
Response and resolution are different tests
A job can receive a fast response and still be at risk.
The terms depend on the agreement, but response commonly concerns the first action, acknowledgement or attendance. Resolution concerns the point at which the issue has been fully resolved under the contract. FM guidance makes the same distinction: response is the initial action on a request, while resolution is the completion of the request itself.1
Consider an illustrative example. A high-priority job is correctly classified and an engineer attends quickly. The response requirement may be met. On site, the engineer identifies a further problem that needs another specialist, customer access to a restricted area or a replacement part. The job is not necessarily resolved. The resolution commitment may still be moving.
A good operational view should therefore show more than “attended” or “complete”. It should make clear:
- which commitment has been met;
- which commitment remains live;
- how much time remains, where that applies;
- what the next action is;
- who owns it; and
- what is preventing resolution if the work cannot yet close.
This prevents a common operational mistake: treating an attendance outcome as evidence that the whole service commitment is under control.
Triage is not just administration
Some SLA risk develops before anyone has opened the schedule.
A service request can be incomplete, incorrectly prioritised or assigned to the wrong contract. The team may not know whether a request sits inside the agreed scope. The site contact may be unavailable. The information needed to allocate the right engineer may not have been captured. Responsibility may be unclear between the customer, provider, landlord or specialist supplier.
The longer those questions remain unresolved, the less time the business has to deliver the requirement.
That is why a strong intake process does more than log a job. It helps the team establish the operational facts that determine the next decision:
- What exactly has been requested?
- Which contract, service category and site does it relate to?
- What priority and commitment apply?
- Is there a response requirement, a resolution requirement or both?
- What information, access and resource are needed to act?
- Who should own the next step if the issue cannot be allocated immediately?
No one should try to interpret contractual terms casually or provide legal advice through an operational workflow. Where the requirement is unclear, the business needs a defined route to confirm it quickly. The important point is that uncertainty itself should be visible; it should not be hidden inside an unallocated job while the deadline approaches.
The scheduling decision is where SLA management becomes real
An SLA target becomes useful only when it is present at the moment a person decides what to do with the job.
A scheduler may be looking at several potential appointments for the same engineer. A calendar can show free time, but free time alone does not show whether a job can be completed within the relevant commitment. The scheduler needs to see the constraint that matters: the applicable target, the remaining time, the resource required, the site/access conditions and the consequence of placing the job at a particular point in the plan.
Strong SLA management should enable a scheduler or manager to answer four questions before a job is allocated or moved:
1. What commitment applies to this job? The priority, response/resolution requirement and any relevant condition should be clear.
2. How much time remains? The team should be able to see whether there is a realistic window for action rather than discover the deadline after the schedule has been changed.
3. Can this resource and appointment meet the commitment? Availability must be tested against skills, travel, existing work, access and the actual time required — not only an apparently empty slot.
4. What happens if the job cannot be placed inside the required window? The decision should become an explicit operational choice, with an owner and an escalation path, rather than an accidental breach created by dragging work into a convenient diary space.
This is the practical difference between having SLA data and using it to manage service delivery.
For example, a good SLA-aware scheduling process should make it immediately clear which appointment options remain inside the relevant SLA window and which would place the work outside it. If circumstances mean the team must choose an option outside the window, the scheduler should have to acknowledge that consequence before proceeding. The job is then not silently turned into a breach; it becomes a visible risk that can be escalated, communicated and reviewed.
The same principle applies to unscheduled work. A job should not wait in a queue until the deadline is already missed. When an SLA-controlled job remains unallocated and its commitment is approaching, the relevant team needs a prompt to intervene while a decision can still affect the outcome.
This is also why SLA control and scheduling cannot be separated from wider capacity management. An engineer who appears free in a diary may not be the right operational answer once skill, travel, site access and existing commitments are considered. The same pressures apply to planned work, as explored in When the PPM Plan Meets the Working Day: changing one commitment can expose another if the team cannot see the knock-on effect.
A job at risk needs an intervention, not only a colour
A red or amber status can be useful. On its own, it does not manage the job.
When a commitment becomes at risk, the business needs a defined next action. That may mean reallocating the work, checking whether another appropriately skilled person can cover it, rearranging a lower-priority commitment, obtaining access, involving a specialist supplier or escalating to a contract manager.
The right action will vary. The operational discipline should not.
A useful at-risk process has three stages:
1. See the risk
The team needs a clear view of the open job, the relevant commitment, the remaining time, current status, assigned owner and constraint. A generic “late” warning is not enough if no one can see what is preventing progress.
2. Decide the intervention
Someone must own the next decision. The team may reprioritise, allocate a different engineer, request access, involve a subcontractor or update the client. The decision should reflect the contract and service context rather than a blanket rule that every job can be treated the same way.
3. Record what changed
The decision, the reason, the customer communication and the revised next action should be visible. Otherwise the operation reverts to messages, phone calls and individual memory — precisely when a later performance conversation needs a reliable record.
The point is not to remove all risk from FM delivery. It is to make risk manageable before it becomes an outcome that cannot be changed.
The evidence trail should be created while work happens
When a client questions performance, the discussion is much easier if both sides can work from the same chronology.
The provider should be able to establish:
- when the request arrived;
- how it was classified and prioritised;
- what service requirement applied;
- when the first action or attendance occurred;
- what work was completed;
- what prevented resolution, if it could not be achieved immediately;
- what escalation and customer communication took place; and
- when the job was completed under the agreed definition.
That record should not have to be reconstructed from email threads, messages, calendars and memories after the event. Reconstructing a timeline is slow, difficult to scale and likely to leave gaps just when the customer needs clarity.
CQ’s existing FM contract management and SLA compliance guide explains the wider value of connected evidence logs and contract records. Operationally, the important principle is straightforward: each meaningful decision should create the context needed for the next person, not disappear into a separate conversation.
Reporting should explain the result, not reveal it for the first time
Monthly SLA reporting matters. It can show performance across sites, service categories, customers and periods. It can support contract reviews and help the business identify recurring service pressure.
But it should not be the first point at which a manager discovers that an issue existed.
Live operational visibility helps the team manage the work while it is open. Reporting helps it learn from the outcome once the work is closed.
The questions in a useful SLA review are not limited to “What percentage did we meet?” They include:
- Which job types repeatedly approach risk?
- Are particular sites, access arrangements or service categories creating pressure?
- Are response issues linked to intake, prioritisation, resource availability or customer information?
- Are resolution issues linked to follow-on work, supplier coordination, parts, access or ownership?
- Does the delivery model still match the commitment made in the contract?
An SLA breach is an outcome. It is not a diagnosis. Knowing why the job was at risk gives the business a better chance of changing its process, resource plan or customer conversation before the same pattern repeats.
Putting SLA awareness inside the scheduling decision
Strong SLA management should not depend on someone remembering a target while moving appointments. The relevant commitment needs to be visible in the operational view where scheduling choices are made.
CQ supports this approach through live SLA-aware scheduling. When an SLA-controlled job is being scheduled or moved, the scheduler can see available scheduling periods highlighted in green where the job remains within the relevant SLA window, and red where the proposed time would fall outside it. If operations mean the job must be placed outside that window, the scheduler must actively acknowledge the decision before proceeding. That makes the service risk explicit instead of allowing an accidental breach to be created without anyone realising.
CQ can also notify the relevant team when an SLA-controlled job remains unscheduled and is approaching its deadline. The value is not the notification itself. It is that the team receives a prompt when intervention is still possible: allocate the work, re-prioritise, escalate, arrange access or communicate a realistic position to the customer.
These capabilities support the wider management discipline described throughout this article. They are not a substitute for clear contract rules, competent triage, realistic resource planning or accountable decisions. They make the relevant information easier to use at the point where those decisions are made.
SLA performance is managed while the work is live
An SLA report tells the business whether it met a commitment. Strong operational control gives the team a chance to protect that commitment before the report exists.
That requires more than a target held in a contract file. It requires the relevant priority, remaining time, capacity constraint, next action and evidence trail to be visible while people are deciding what to do.
For FM providers, that protects more than a monthly percentage. It protects service delivery, customer confidence and the management time otherwise spent chasing what happened after the decision has already been made.
If your business is assessing whether its current systems still support this level of operational control, CQ’s guide on how to choose job management software when scaling offers a broader decision framework. To see how CQ connects scheduling, jobs, operational evidence, customer information and financial visibility in one working system, explore CQ's FM Business Management Software.
To see how CQ could support SLA-aware scheduling and live service visibility in your own FM operation, book a CQ demo.
Frequently asked questions
When does an SLA clock start in facilities management?
The relevant start point is defined by the contract or service specification. It may be tied to receipt, validation, classification, request logging time, agreed working hours or another stated condition. The operational priority is to make the applicable rule visible early enough for the team to act on it.
What is the difference between SLA response time and resolution time?
Response time concerns the agreed first action, acknowledgement or attendance, depending on the contract. Resolution time concerns the point at which the issue is fully resolved under the agreement. A job may meet its response target but still require active management against the remaining resolution commitment.
Why is an SLA report not enough?
An SLA report is retrospective. It shows whether targets were met after jobs are closed. Live visibility helps managers identify which open jobs are approaching risk and make an intervention while there is still time to influence the outcome.
