Dental IT Support SLA: Response Times, Escalation and What Your Agreement Should Define

The renewal is on your desk, or a new provider has sent a proposal, and somewhere on page four it says "critical issues: 15-minute response." It sounds reassuring. But you have lived through a morning when the imaging bridge stopped working, someone replied quickly, and the operatory still waited half the day for a fix.

Here is the direct answer. A dental IT support SLA should define how incidents are prioritized, what "response" means, when work must start, how escalation happens, how often you get updates, how onsite and after-hours work are handled and what is excluded. Then it should say what evidence you receive each month to prove the service matched those words.

This guide is written for the practice owner or office manager who is comparing agreements. It covers what to put in the SLA, sample clause wording you can bring to a contract review, and a worksheet for checking the service after you sign. If your real question is price, the dental IT support cost guide covers how to compare quotes line by line. If you have already decided to leave your current provider, the guide on how to switch dental IT providers without downtime covers the handover plan.

What is a dental IT SLA, and what should it actually say?

A dental IT SLA is the part of your support agreement that turns "we'll take care of it" into written service levels: how urgent problems are ranked, how quickly work starts, when an issue moves to a senior engineer, how often you are updated and what proof you receive. It is a measurement contract, not a promise that nothing breaks.

In practice, a useful SLA answers eight questions in writing. A provider that cannot point to where each answer lives in the signed documents is asking you to trust a conversation, not an agreement. Gaps like that are among the signs your IT provider is falling short, and they are easier to raise before renewal than after.

Written service levels are mostly a feature of recurring support agreements. If you are still choosing the model itself, the comparison of managed dental IT vs break-fix support explains the difference, and dental IT support vs general IT support covers why a dental office needs priority definitions written around operatories, imaging and the patient schedule rather than around generic office work.

The rest of this page goes through each row, starting with a real morning and a real patient in the chair.

The 8:07 AM test: can your SLA explain the next 30 minutes?

It is 8:07 in the morning. The first patient is already in the chair. One operatory cannot open yesterday's images. A minute later, a second operatory reports the same thing.

The practice does not care whether the ticketing system says "acknowledged." It needs to know what happens next: who owns the issue, how urgent it is, when technical work actually starts, whether there is a workaround, who contacts the imaging vendor, and how the office manager will be updated.

An illustrative patient-day incident timeline has eight steps:

If the agreement can only promise "fast response," it is not specific enough for a technology-dependent dental practice.

Put one realistic scenario in front of the provider:

A mature provider should be able to walk through the process without inventing it on the call. Listen for names of roles rather than names of people, for the point at which a second technician joins, and for the moment the office manager hears what is happening. If you are still deciding what kind of support model fits your practice, read the overview of managed IT services for dental practices and the Managed IT Services Buyer's Guide.

• Read:managed IT services for dental practices
• Read:Managed IT Services Buyer’s Guide

Response time is not resolution time

A provider can acknowledge a ticket in minutes and still take much longer to restore the workflow. Buyers should ask which clock the advertised number refers to. Most published "response times" measure only the first clock below. The other four are where a dental practice actually feels the difference.

When does the SLA clock start, pause and stop?

The clock usually starts when the provider receives the ticket or detects the problem, pauses when the provider is waiting on the practice or an outside party, and stops when the defined milestone is met. Each of those words needs a written definition, because two agreements with the same number can measure very different service.

Questions to settle before you compare numbers:

• • Start. Does the clock start at the phone call, at the ticket's creation, or when the provider's monitoring raised an alert? Published MSP agreements vary on this; some start timers only once the incident information is complete. If your staff report by phone, the start should be the call, not the moment someone later types it up.
• • Hours. Is the target counted in business hours or calendar hours? A two-business-hour target on a ticket opened late on a Friday afternoon may not fall due until Monday morning. That may be fine for a routine request. It is not fine for a practice that opens Saturday.
• • Pause. Which reasons stop the clock? "Waiting on customer" is reasonable when the provider needs someone to restart a device or approve a change. "Waiting on vendor" deserves a closer look: the provider can still be accountable for chasing the vendor and keeping you informed while the clock is paused.
• • Stop. Which milestone stops each clock? Engagement stops when work starts. Restore stops when the workflow works. If the agreement uses one word, "resolved," ask whether it means a workaround, a restore, or a confirmed fix.
• • Reopen. If the same problem comes back the next morning, is it the same ticket or a new one? A reopened ticket should count against restore, not reset it.

None of this needs to be adversarial. Most providers have these rules inside their ticketing system already. The point is to see them before you sign, so the monthly report means what you think it means. The same check applies whether you are renewing your current IT support for dental practices or comparing proposals from new providers.

What is a good IT response time?

A good IT response time is one that matches the severity of the problem and is defined precisely: a practice-stopping issue needs qualified engagement measured in minutes during your hours, while a routine request can reasonably be measured in business hours or days. A fast acknowledgement with a slow, unowned restore is not good service.

There is no single correct number, and any page that gives you one without asking how your practice runs is selling, not advising. Published managed-service agreements we reviewed this month tend to follow the same shape: the most urgent level is expressed in minutes, the middle levels in hours, and routine requests in business hours or days. The numbers themselves vary widely, and they are rarely measured the same way.

So instead of asking "what is your response time?", ask four narrower questions:

1. 1. Which clock is that number? Acknowledgement, engagement, workaround or restore.
2. 1. Which priority level does it apply to, and who decides the level? A great P1 number is no help if most of your problems are quietly filed as P3.
3. 1. During which hours? Your clinical hours, the provider's business hours, or all hours.
4. 1. What did you actually achieve last quarter? A provider that measures its service should be able to show its own results for a comparable client, without naming the client.

The answer to the fourth question tells you more than the number in the proposal. A provider that targets a modest time and meets it, with a report to prove it, is easier to plan around than one that advertises an impressive figure and cannot show how often it is met.

This page deliberately states no Legend response-time figure. Ask any provider, including us, to put the written service levels in the proposal and to show how they are reported.

Priority should reflect patient and production impact

Generic IT severity systems can be misleading in a dental office. One computer is not automatically low priority if it is the only workstation available for a critical clinical workflow. Ten affected devices are not automatically critical if a safe workaround keeps the practice operating.

A useful severity model considers:

• • Patient-care or clinical-workflow impact
• • Number of users or operatories affected
• • Whether an entire location is affected
• • Access to critical clinical or business information
• • Security or data-exposure risk
• • Whether a safe workaround exists
• • Whether the issue is getting worse or spreading

Two more factors are specific to dental work. The first is time of day: an imaging failure before the first patient, with a full hygiene schedule ahead, is more urgent than the same failure ten minutes before closing. The second is the chain behind a device. A sensor that will not capture may be a USB port, a driver, the imaging bridge to Dentrix, Open Dental or Eaglesoft, or the imaging server itself. The priority should follow the patient impact, not the size of the device that broke.

P1, P2 and P3 labels are only useful if the definitions are written

Labels such as P1, P2 and P3 only help when both sides agree, in writing, what belongs in each. The definitions below are illustrative; your agreement should define its own, with dental examples, so nobody argues about the level while a patient waits.

Do not copy these labels into a contract without tailoring them. The important thing is that the provider and practice use the same definitions before an incident occurs. It helps to attach examples that your own team would recognise:

The P4 row matters more than it looks. When routine requests share a queue and a clock with real incidents, the monthly report can look healthy while a P1 waited behind a password reset. Ask whether requests are measured separately.

Escalation matters more than a fast first reply

Escalation is the written path a ticket follows when the first technician cannot fix it. It names the triggers, the next level, who owns a major incident, and how the practice can ask for escalation itself. A provider with a fast first reply and no escalation path will often be fast to say "we're looking into it" and slow to fix anything.

The best first-line technician cannot solve every network, server, cloud, imaging or security problem. The SLA should explain how a ticket moves when the first resource cannot resolve it.

• • What conditions trigger escalation?
• • Can the practice request escalation?
• • When does a senior engineer become involved?
• • Who owns a major incident across multiple technicians?
• • Who keeps the practice informed while several teams work?
• • What happens when the issue is blocked by a third-party vendor?

A useful escalation clause has three kinds of trigger. Time triggers move a ticket up when a clock is close to being missed. Impact triggers move it up when more operatories or a second location are affected. Request triggers let the office manager say "please escalate" and have that recorded in the ticket. The third one is the easiest to leave out and the one practices most often wish they had.

The Dental IT Network Operations Center article goes deeper into the operating structure behind escalation. This page owns what the agreement should require.

• Read:Network Operations Center

Dental software and imaging vendors make SLA wording more important

A common support failure happens when the IT provider says "call the software company" and the software company says "it is the network." The dental team becomes the messenger.

A practice depends on several vendors at once: the practice-management system (Dentrix, Eaglesoft, Open Dental, Denticon, Curve), the imaging software (DEXIS, Carestream, Planmeca Romexis, Vatech), Microsoft 365 for email, a phone platform, an internet carrier and often a payment processor. Each has its own support desk and its own idea of where its responsibility ends.

Your agreement should explain the provider's role when another vendor is involved. A useful process may include five steps:

The SLA does not need to promise another vendor's response time. It should explain whether your IT provider remains accountable for coordination, and whether that coordination is inside the monthly agreement or billed as separate work. Both are legitimate; finding out during an outage is not.

Cloud and Microsoft 365 outages: what can your IT provider control?

When a cloud service such as Microsoft 365 or a cloud practice-management system has an outage, your IT provider cannot fix the vendor's platform. What it can control is how quickly it confirms the outage, what workaround it offers, how it keeps you informed and how it checks your systems once the vendor restores service.

That distinction belongs in the SLA, because more of a dental office now runs on services the IT provider does not operate. Microsoft, for example, publishes its own service level agreement for its online services as a separate document, and its admin center has a service health page that shows active incidents and advisories. Microsoft's own guidance is to check service health "to determine whether this is a known issue with a resolution in progress before you call support or spend time troubleshooting."

A reasonable clause for cloud outages asks the provider to:

• • Check the vendor's status page or admin center and tell the practice whether the problem is the vendor's, local, or unknown.
• • Offer a workaround where one exists (for example, the web version of an app, a phone hotspot, a different browser or a printed schedule).
• • Keep updating the practice at the agreed cadence, even when the only news is the vendor's latest status.
• • Test the practice's own workflows once the vendor reports the service restored, and close the ticket only after that check.

Microsoft's status vocabulary is a useful model for your own updates: "Investigating", "Service degradation", "Service interruption", "Restoring service", "Extended recovery" and "Service restored", and, for some issues, "Post-incident report published" with root-cause information. You do not need those exact words, but you do want a provider whose updates tell you which stage you are in. If your internet line itself is the problem, the guide to what to do when the dental office internet goes down covers the outage plan.

After-hours coverage must be defined separately from monitoring

For each one, the agreement should say:

• • Monitoring: what is watched (servers, backups, firewalls, internet, workstations), what creates an alert, and whether an overnight alert becomes a ticket that someone acts on before the practice opens.
• • Human support: which hours a person answers, which number or channel to use, and whether after-hours calls are handled the same way as daytime ones.
• • After-hours work: whether after-hours fixes, maintenance and projects are billed differently, and who approves them.

Ask for one example: a backup fails in the middle of the night on a Tuesday. Who sees it, what happens, and what will the office manager know when the office opens? Use the 24/7 IT monitoring article to decode monitoring. Use the 24/7 Dental IT Helpdesk article for the human-support question.

• Read:24/7 IT monitoring
• Read:24/7 Dental IT Helpdesk

Onsite response needs its own rules

Many incidents can be resolved remotely. Some require hands on hardware, cabling, network equipment or another physical device. Onsite work has a different clock from remote work because it includes a dispatch decision and travel, so a remote engagement number tells you nothing about when a technician will be at the door.

The agreement should make clear:

• • Which incidents qualify for onsite service
• • Where onsite service is available
• • Whether remote diagnosis happens first
• • How dispatch priority is determined
• • Whether travel or after-hours charges apply
• • What happens if replacement hardware or parts are required

Do not assume the phrase "onsite support available" means immediate arrival. A clearer clause separates three times: when the provider decides a visit is needed, the arrival window it commits to for that priority, and what happens while you wait (remote workaround, a loaner device, a part shipped). It should also say whether onsite visits are counted in the monthly report, so you can see how often remote work was enough.

Communication is part of the service level

A practice-stopping issue becomes more stressful when the office manager has to chase the provider for status.

A mature SLA should define who communicates during a major incident and how often. Even when the technical team cannot yet promise a resolution time, it should be able to explain the current diagnosis, next action, blocker and next update.

Good communication clauses usually cover four things: the channel (phone call for P1, ticket updates for the rest), the cadence by priority, the audience (office manager, owner, and for groups the operations lead at each affected location), and the close-out note, which says what was done and whether any follow-up remains. Communication also runs the other way. The practice should name who can approve changes and who can request escalation, so the provider is not waiting on someone who is chairside.

Ask what is excluded before you compare response promises

A recurring support agreement may exclude major projects, cabling, unsupported devices, large migrations, new-office buildouts, after-hours project work, third-party fees or hardware replacement.

An exclusion is not automatically a problem. An unclear exclusion is.

Exclusions also change how you read the service levels. A response target that applies only to "supported devices" means little if the imaging acquisition PC is not on the supported list. A restore target that excludes "third-party applications" may exclude the systems your day depends on. Ask for the supported-device list and the exclusions list together, and check that your critical systems appear on the first and not the second. The dental IT support cost guide shows how to mark each line of a quote as included, extra or not stated.

Sample SLA clause wording you can bring to a contract review

You can bring plain-English clause wording to a contract review even if you are not a lawyer: it gives the provider something specific to accept, amend or explain. The sample below has blanks for the numbers and is a starting point for the conversation, not legal advice. Your attorney should review any contract you sign.

Copy the parts that fit and fill the blanks with what the provider proposes:

Clause 8 follows a line in federal guidance for managed service provider customers. CISA's advisory on threats to managed service providers says "contracts should detail how and when MSPs notify the customer of an incident affecting the customer's environment," and that customers should ensure "their contractual arrangements include incident response and recovery plans" that meet their resilience and recovery requirements. Your business associate agreement may also address security incident reporting; the SLA should not contradict it.

Expect a provider to push back on some blanks. That is normal. What you are listening for is whether it can explain its numbers and how it measures them, not whether it agrees to every figure.

The 12-point dental IT SLA scorecard

Score each agreement you are comparing. A missing point is a question for the provider, not an automatic reason to walk away.

Two quick additions make the scorecard sharper: write down where in the documents each point is answered (page and section), and mark whether it is measured in the monthly report. A point that is written but never measured is a hope. If the offboarding point is weak, read how to switch dental IT providers without downtime before you sign, because exit terms are easiest to agree at the start.

• Read:switch dental IT providers

Red flags in an SLA conversation

When should a dental practice review its SLA?

The support model that worked for one location may not fit five. Review the agreement when the practice adds locations, extends operating hours, changes practice-management software, adds major imaging systems, moves infrastructure, adds internal IT staff or experiences a significant outage.

Two more triggers are worth adding to the calendar. Review it at every renewal, even if nothing changed, because the provider's own service model may have. And review it after any P1 incident where the practice felt the response did not match the paper: replay the incident against the clauses and see which one was missing or unclear.

Where SLA language may live in the contract set

Providers structure agreements differently. Response commitments, exclusions and escalation rules may appear in a master services agreement, statement of work, service schedule or support policy rather than one document titled "SLA."

The buyer's job is not to insist on a particular document name. It is to make sure the commitments are written somewhere in the signed service package and can be found when an incident occurs.

Watch for one detail in particular: whether the support policy can be changed by the provider without your signature. A policy page on a website that "may be updated from time to time" is weaker than a schedule attached to your agreement. If a document can change, ask how you will be told. And because your IT provider handles systems with patient information, the business associate agreement sits in the same contract set. The HIPAA Security Rule's business associate contract section includes a requirement that the business associate "Report to the covered entity any security incident of which it becomes aware" (the paragraph goes on to cover breach reporting). How your BAA handles that is a question for your counsel; the point for the SLA is that its security-event clause should be consistent with the BAA, not a second, different promise.

How to measure the service after the contract is signed

A dental practice should not evaluate managed IT only by whether the provider hit one response-time number. A quarterly or 90-day review can look at a small set of operational measures:

The goal is not to turn the dental office into a call-center analytics team. It is to verify that the written service model is producing the experience the practice bought. The next section turns these measures into a monthly worksheet.

What monthly evidence proves the SLA is being met?

The evidence is a monthly ticket export plus a short summary: every ticket with its priority, timestamps for each clock, pause reasons, escalations, onsite visits and vendor cases. With that, an office manager can check the SLA in one short sitting each month. Without it, the practice only has impressions.

This is the service-evidence worksheet. Ask for the export in a spreadsheet format, not a PDF, so you can sort it.

The ticket export: fields to ask for

Ask for one row per ticket with at least these fields: ticket number, location, device or system, priority at open and close, category, created time, first human reply, engagement time, workaround time, restore time, closed time, pause reasons with durations, escalation flag and level, onsite flag, vendor case number, reopen flag and a one-line summary. Most professional ticketing systems can export these. If a field does not exist, ask how the provider measures that clock without it.

The P1 timeline record

For every P1, ask for a short timeline in the same order as the 8:07 steps: report, classify, engage, workaround, escalate, vendor, restore, validate, with a timestamp for each. Add one paragraph on cause and one on prevention. NIST's incident response guidance (SP 800-61 Rev. 3) frames incident response as part of ongoing risk management, aimed at reducing "the number and impact of incidents"; a P1 record with a prevention line is how a small practice does the same thing.

First response vs restore: read both

Put the engagement time and the restore time for each P1 and P2 next to each other. A provider that is quick to engage and slow to restore may need better escalation. A provider that is slow to engage but restores fast once started may need more people at the front of the queue. Look at the longest tickets, not only the average, because one long P1 matters more to a patient day than ten quick fixes.

Escalations and reopen rate

Count how many P1 and P2 tickets escalated, and how many tickets of any priority were reopened. The reopen rate is the simplest quality check there is: if "resolved" tickets keep coming back, the restore clock is being stopped too early. The NOC guide explains why recurring incidents are a maturity test for the operations side.

Onsite visit log

List each onsite visit with the reason, the dispatch decision time, the arrival time and the outcome. Over a quarter this shows whether visits are going to the right problems and whether parts or hardware are the real delay.

Vendor-escalation log

List every ticket that involved an outside vendor: the vendor, the case number, whether there was a joint call and who closed the loop with the practice. This is where "the IT company says it's the software, the software company says it's the network" either shows up or stops.

Security events

List security-related tickets separately, with the time the practice was notified. The HIPAA Security Rule's administrative safeguards include procedures to "regularly review records of information system activity" and to "Identify and respond to suspected or known security incidents"; a monthly list of security tickets is part of the record a practice can keep. It is not a substitute for your own risk analysis or for advice from counsel.

How do you run a quarterly SLA review?

A quarterly SLA review is a 45-to-60-minute meeting where the provider walks the practice through three months of ticket evidence, the P1 records, repeat problems and planned changes, and both sides agree on fixes. It keeps the agreement current and stops small service gaps from becoming the reason you switch.

A workable agenda:

1. 1. Numbers against the clauses (10 minutes): engagement and restore by priority, compared with the targets; the longest five tickets; reopen rate.
2. 1. P1 records (10 minutes): each P1 timeline, its cause and its prevention step, and whether the prevention was done.
3. 1. Repeat problems (10 minutes): the top three categories by ticket count and what would remove them (a hardware refresh, a settings change, training).
4. 1. Vendors (5 minutes): open vendor cases and whether any vendor keeps appearing.
5. 1. Security and monitoring (5 minutes): security tickets, notification times, alerts that repeat.
6. 1. Changes coming (5 minutes): new locations, software changes, hours changes, staff changes that affect the SLA.
7. 1. Agreement changes (5 minutes): any clause that needs rewriting, recorded with an owner and date.

Keep a one-page note of each review. After a year you have four notes, which is the best evidence you will ever have at renewal time. The NOC guide covers what a broader monthly operations review should include; this agenda stays on the SLA.

A useful major-incident update is simple

A good update can be four lines long: "Imaging down in Ops 2 and 3. The imaging server is running; we have ruled out the network switch. Next: we are on a call with the imaging vendor now. Next update 8:45." Adding a status word such as "investigating" or "restoring service" tells the office manager at a glance which stage the incident is in.

What to ask your IT provider about its SLA

Bring these questions to a renewal or a proposal meeting. Ask for the answers in writing, and note where in the agreement each one lives.

• • Which clock does your response number measure: acknowledgement, engagement, workaround or restore?
• • What are your priority definitions, and can we attach dental examples to them?
• • Who decides the priority, and can the practice ask for it to be reviewed?
• • Are your targets counted in business hours or calendar hours, and whose hours?
• • What pauses the clock, and is each pause recorded with a reason?
• • What happens to a ticket that reopens the next day?
• • What triggers escalation, and can our office manager request it?
• • Who owns a P1 incident from start to finish?
• • When our imaging or practice-management vendor is involved, what do you do, and is that inside the monthly fee?
• • During a Microsoft 365 or cloud outage, what will you tell us and how often?
• • What happens between an overnight monitoring alert and our opening time?
• • How do you decide on an onsite visit, and what arrival window applies to each priority?
• • How and when do you notify us of a suspected security incident?
• • What will we receive each month, and in what format?
• • Can you show a sample monthly report for a practice like ours, with the client's details removed?
• • What did you achieve against these targets last quarter for comparable clients?

How Legend Networking describes its own service model

This page is meant to help you compare any provider, including us, so here is what we can state about Legend Networking, in the words we use everywhere:

• • Helpdesk: Helpdesk staffed 24/7 at 1-800-794-1588, one general number.
• • Monitoring: 24/7 monitoring.
• • Engineers: In-house engineers; no outsourced first-level triage.
• • Onsite: Onsite dispatch by appointment across served dental markets; remote-first nationwide.
• • Track record: Served over 3,500 practices since 2004. 4.8 rating · 173 Google reviews.
• • Operations: Legend's operations are led by Ian Lynch: 22 years in dental IT; oversees the NOC, onsite dispatch and client technology roadmaps.

We do not state response, update or arrival times on this page. Put a Legend proposal through the same questions, clauses and worksheet as everyone else's, and ask us to show where each answer lives in writing.