Service level expectations help create accountability, consistency, and transparency between your organization and your Managed IT Department. They establish measurable expectations for how quickly a new support request should receive a human response based on its business impact. We also measure additional internal targets for technical engagement and resolution so that we can continuously evaluate and improve the performance of the IT department. These targets should not be read as the amount of time we expect you to wait. The Response commitment represents the outer service-level window under normal qualifying service conditions. Our goal is always to respond and engage sooner, and we commonly outperform these targets.
The most important distinction: Response is the only time-based SLA commitment under our standard service model, subject to the applicable Quote, Services Guide, departmental business hours, and contractual exceptions. Plan is a published operational performance target. Resolution is a published best-effort performance target. We measure both for accountability, transparency, and continuous improvement. Neither Plan nor Resolution is a guaranteed completion deadline.
The dashboard uses three measurements for each support priority. Response is the time-based SLA commitment. Plan and Resolution are additional performance targets we publish and measure for transparency.
| Priority | Respond Within | Plan Within | Resolve Within |
|---|---|---|---|
| P1 – Critical | 2 hours | 4 hours | 8 hours* |
| P2 – High | 4 hours | 8 hours | 16 hours* |
| P3 – Normal | 8 hours | 16 hours | 32 hours* |
| P4 – Low | 16 hours | 32 hours | 64 hours* |
*Resolution is always best effort. The Resolve Within number is used to measure support performance and does not create a guaranteed completion commitment.
A Managed IT Department should be measurable. Service level reporting gives clients and EasyITGuys leadership a consistent way to evaluate how well new requests are being received, routed, technically engaged, and managed over time.
This helps us identify:
The goal is not to manage IT by stopwatch. The goal is to establish clear expectations, measure our performance, identify problems early, and continuously improve the service your organization receives.
| Service Levels Are Good For | Service Levels Are Not Designed To Do |
|---|---|
| Measure how quickly new requests receive human attention | Predict exactly how long an unknown technical problem will take to solve |
| Create accountability for the Managed IT Department | Eliminate vendor, hardware, software, scheduling, or dependency delays |
| Prioritize requests based on business impact | Make every technical issue equally urgent |
| Measure performance and trends over time | Replace communication, troubleshooting, planning, or change management |
EasyITGuys did not create the underlying principles of service-level management. Our approach is built around established IT service-management concepts: define clear expectations, prioritize work according to business impact, measure performance, communicate responsibilities, and use the results to continually improve service. Plan Within is an EasyITGuys operational service-management milestone. We are not presenting “Plan Within” as a universal ITIL or NIST term. It is an additional measurement we use to provide visibility into how quickly technical engagement begins after the initial Response.
| Industry Reference | Relevant Principle | How It Connects to Our Process |
|---|---|---|
| NIST – Service Level Agreement (SLA) | Service levels establish provider and customer responsibilities and expected performance, including response times, reporting, and resolution-related expectations. | Our Response commitment and published Plan and Resolution measurements create clear expectations and measurable accountability. |
| ITIL 4 / PeopleCert – Service Level Management | Service targets should be clear and based on the needs and impact of the business. | Our priority model focuses on business impact rather than job title, frustration level, or who submitted the request. |
| IT Service Management Platforms | Modern ITSM systems commonly use impact and urgency to establish incident priority and drive service-level management. | Our support workflow similarly uses business impact to determine how a request should be prioritized and managed. |
The principles are industry established; the specific targets are ours. Recognized IT service-management practices support clear service expectations, business-impact-based prioritization, measurement, reporting, and continual improvement. EasyITGuys defines the specific Response, Plan, and Resolution targets used within our own service model.
Your service dashboard may display three different measurements:
| Dashboard Measurement | What It Means | Commitment Type |
|---|---|---|
| Respond Within | A person has reviewed the new request and provided human acknowledgment, triage, routing, assignment, or other meaningful response. | Guaranteed service-level commitment* |
| Plan Within | A technical team member has personally reviewed the request and established or begun the next working path. | Operational performance target |
| Resolve Within | A performance target for how quickly we aim to drive a ticket of that priority toward completion. | Best-effort performance target |
*The Response commitment is subject to the applicable Quote, Services Guide, departmental business hours, service scope, and contractual exceptions. Client-specific terms may differ.
Response answers: “Has a person reviewed and responded to my new request?”
Plan answers: “Has the technical team engaged and established the next path forward?”
Resolution answers: “How quickly are we ultimately driving the request toward completion?”
This is an important part of understanding the dashboard. When you submit a ticket electronically, you may receive an immediate automated confirmation showing that our ticketing system successfully received your request. That automated receipt does not satisfy the Response or Plan measurement. Response and Plan require human engagement.
| Stage | What Happens | SLA Meaning |
|---|---|---|
| Ticket Received | The ticketing system confirms that your request was received. | Automatic confirmation only. This does not satisfy Response or Plan. |
| Human Response | A team member reviews the request, considers priority and routing, and personally responds, acknowledges, assigns, or triages it. | Respond Within milestone |
| Human Technical Engagement | A technical resource reviews the request and begins or establishes the appropriate next path. | Plan Within milestone |
| Work Continues | Troubleshooting, communication, scheduling, escalation, vendor coordination, testing, or change management continues as needed. | Normal ticket lifecycle |
| Resolution | The issue is resolved, an appropriate outcome is reached, or another approved path is established. | Best-effort Resolve Within target |
Respond Within measures the first meaningful human response to a new support request. For an emailed, portal, or other asynchronous request, a member of the team reviews the request and begins the support workflow. That may include:
Response does not mean resolution. It means a person has reviewed your new request and the Managed IT Department has begun managing it.
Plan Within measures the next level of technical engagement. A technical team member has personally reviewed the request and established or begun the next working path.
Depending on the issue, that path may include:
A Plan does not mean that every answer is already known. It also does not necessarily mean that a formal written project plan has been created. “Plan Within” is the operational milestone used by our service-management and reporting system. It should not be confused with a formal project plan or interpreted as a separate contractual SLA commitment.
Plan Within means the technical team has engaged and established the next path forward. It is an operational target we measure for accountability. It is not a guaranteed resolution deadline.
Response and Plan targets are easiest to see with asynchronous requests such as email or portal submissions because the request may enter a queue before a person begins working with it. Live support is different.
| Support Method | Response | Plan / Technical Engagement |
|---|---|---|
| Email / Portal / Asynchronous Request | A person reviews and responds to the new request after it enters the support workflow. | A technical resource then reviews the request and establishes the next path. |
| Phone / Live Chat With Support | Occurs during the live human interaction. | Also occurs during the live interaction because technical engagement is already underway. |
This is why phone and live-chat tickets may show extremely fast Response and Plan results on your dashboard. You were already interacting with a person, so both human-engagement milestones occurred during the live support experience.
The table below explains the standard P1 through P4 targets displayed in our service management and reporting systems. Times are measured using the applicable departmental business/service calendar unless your Quote or other governing service document states otherwise.
| Priority | Typical Business Impact | Respond Within | Plan Within | Resolve Within |
|---|---|---|---|---|
| P1 – Critical | Major organizational outage or critical business service unavailable with broad operational impact and no reasonable workaround. | 2 hours | 4 hours | 8 hours* |
| P2 – High | Multiple users or an important business function are significantly affected, but the organization can still operate in a reduced capacity or through a workaround. | 4 hours | 8 hours | 16 hours* |
| P3 – Normal | A single user or limited number of users cannot perform normal work, while the broader organization remains operational. | 8 hours | 16 hours | 32 hours* |
| P4 – Low | Low business impact. Work can continue, but the user or organization is inconvenienced. | 16 hours | 32 hours | 64 hours* |
These are typical business-impact examples. Actual priority is based on the overall business impact, scope, availability of a reasonable workaround, and the circumstances of the request.
| Respond Within | The time-based SLA commitment under our standard service model, subject to the applicable Quote, Services Guide, departmental business hours, and contractual exceptions. |
| Plan Within | Published operational performance target for technical engagement and establishing the next path forward. It is not a separate contractual SLA commitment. |
| Resolve Within | Published best-effort performance target. It is not a guaranteed completion deadline. Resolution is always best effort. |
Do not read these numbers as expected wait times. Response is our time-based SLA commitment, while Plan and Resolution are additional performance targets we measure for accountability and transparency. We continually work to respond, engage, and resolve requests sooner whenever circumstances allow.
Priority is based primarily on business impact. This allows the Managed IT Department to direct resources toward the requests that have the greatest effect on the organization. EasyITGuys may confirm or adjust a priority after reviewing the actual impact of the request.
| What Can Affect Priority | What Does Not Automatically Set Priority |
|---|---|
| Number of users unable to work | The job title of the person submitting the ticket |
| Loss of a critical business function | How frustrating the issue feels to one person |
| Organization-wide or department-wide downtime | A requested completion date by itself |
| Availability of a reasonable workaround | Whether the request came from an owner, executive, manager, or end user |
| Operational, security, or business continuity impact | A request to label a ticket “urgent” without corresponding business impact |
An owner or executive request can certainly receive additional visibility, communication, and coordination. High visibility is not a separate SLA priority. The underlying priority remains based on business impact.
P5 is generally associated with planned work, preventative maintenance, longer-term requests, projects, or changes that are not being handled as a normal incident. Planned work is different from an outage or support incident because the work may require:
The timing for planned work therefore follows the applicable Service Guide, Quote, approved scope, project schedule, or change-management process. A requested deadline is important information and should always be shared with us. It does not automatically convert planned work into a higher incident priority or remove the need to plan a meaningful infrastructure change safely. For more information, see IT Change Management: Why Scoping and Planning Matter and Covered and Non-Covered Projects: How Managed IT Project Coverage Works.
Your dashboard may display a Goal Percent of 90% beside Response, Plan, and Resolution measurements. This is a performance-management threshold used to evaluate trends across a population of qualifying tickets. It helps leadership identify when service performance may need attention.
For example, a declining percentage may lead us to review:
Response and initial technical engagement are processes that the IT department can largely control. Resolution is different. Final resolution can depend on factors that are not fully within our control, our standard service model treats Resolve Within as a best-effort performance target rather than a guaranteed completion commitment. When a support request first arrives, nobody can reliably know everything that troubleshooting will uncover. A problem that appears simple can remain simple. It can also reveal a much larger issue.
For example, a ticket that begins as “I cannot open the application” could ultimately involve:
| We Can Strongly Control | Resolution May Also Depend On |
|---|---|
| How quickly a new request receives human review | Hardware or software vendors |
| How the request is prioritized and routed | Internet, telecommunications, cloud, or utility providers |
| How quickly technical engagement begins | Replacement parts, shipping, warranties, and licensing |
| Communication, documentation, and escalation | User availability, approvals, scheduling, and testing |
| Following established troubleshooting and change processes | Complexity, dependencies, security requirements, and what troubleshooting discovers |
A Resolve Within target helps us measure performance. It cannot turn an unknown technical problem into a guaranteed completion time.
Best effort means the final completion time cannot always be promised in advance. It does not mean that the request is unimportant or that work stops when a dashboard target is reached. The support team continues managing the request according to its impact, technical findings, dependencies, communication needs, and available path to resolution. Sometimes the healthiest outcome is immediate remediation. Other times it is escalation, vendor involvement, equipment replacement, a scheduled change, or a properly scoped project. Professional IT is not about forcing a fast answer when the facts do not support one. It is about making the correct diagnosis, communicating clearly, protecting the environment, and moving the request toward the right outcome. For additional context, see Best Effort IT Support: What Does It Mean?
Response and Plan apply to the initial support request. They are one-time milestones in the lifecycle of that ticket.
They do not create a new Response or Plan SLA every time:
Once the request has received its initial human Response and technical Plan engagement, it continues through the normal support workflow until an appropriate outcome is reached. You may still request an update, provide new information, ask for escalation, or call at any time.
Assume a P2 – High request is submitted electronically.
| Stage | P2 Target | What It Means |
|---|---|---|
| Ticket Submitted | Start | The original request enters the support workflow. |
| Respond | Within 4 hours | A person has reviewed and responded to the request. |
| Plan | Within 8 hours | A technical resource has engaged and established or begun the next path forward. |
| Resolve | 16-hour target | Best-effort completion target. Actual resolution depends on what is discovered and what is required. |
Now consider the same P2 request through a live phone or chat interaction with Support:
Response: Immediate during the live interaction.
Plan: Immediate during the live technical engagement.
Resolution: Still best effort and dependent on the actual technical issue.
Call. If you want immediate support, a phone call is the fastest way to create or continue a support interaction. Email and portal submissions are excellent for normal requests, documentation, screenshots, attachments, and situations where immediate interaction is not required. A live support interaction is different because a person is already engaging with you. If the business impact changes after a ticket was created, tell us. Reply to the ticket or call so the team can reassess the priority.
Urgent? Call. A higher priority determines how the request is classified based on business impact. Calling determines how quickly you can begin a live interaction with the Support team.
This section applies to support requests and SLA measurement. Contract notices, Authorized Contact changes, billing matters, legal communications, and other administrative requests may have different required communication methods under the applicable agreement. For a service level to be measured, the request must first reach the Managed IT Department through an authorized support channel. This is important because the support system is what allows a request to be:
An SLA cannot begin until the request enters an authorized, trackable support workflow. If the IT Department has not received the request through an approved support channel, the service-management system cannot reliably measure, route, prioritize, or guarantee a response to it.
Use the approved support method for the team or service you need. Depending on your organization and service plan, authorized channels may include:
The exact contact methods available to your organization may vary by department, service, or agreement.
Communication sent outside the approved support workflow may not be seen promptly, may not reach the correct team, and may not create a support ticket.
| Communication Method | SLA Status | Why |
|---|---|---|
| IT Support Panel / Approved Support Application | Authorized | Creates or enters the request into the tracked support workflow. |
| Designated Support Email | Authorized | Routes the request into the appropriate support system and team. |
| Correct Support Telephone Number | Authorized | Creates a live support interaction and allows the request to be documented immediately. |
| Approved Support Chat or SMS | Authorized when connected to the support workflow | The communication is received through a supported, trackable service channel. |
| Direct Email to an Individual Employee | Best effort / Outside SLA | The employee may be unavailable, off duty, on vacation, in meetings, or may not be the appropriate resource. |
| Personal Text Message to a Staff Member | Best effort / Outside SLA | A personal message does not automatically create, prioritize, route, or track a support ticket. |
| Calling an Unrelated or Non-Support Number | Best effort / Outside SLA | The communication may not reach the appropriate support workflow or technical team. |
| Physical Letter, Note, or Other Offline Communication | Best effort / Outside SLA | The request is not automatically entered into the service-management system and cannot be reliably measured or routed. |
| Other Unapproved Communication Method | Best effort / Outside SLA | Service-level measurement requires the request to enter an authorized support workflow. |
We will still try to help. If an EasyITGuys team member notices an off-channel request, they may redirect it, create a ticket, or help move the communication into the proper workflow. However, communications sent outside authorized support channels are handled on a best-effort basis. There is no guaranteed Response, Plan, communication, or Resolution timeframe while the request exists only outside the authorized support workflow.
If an off-channel request is later entered into the ticketing system, service-level measurement begins when the request reaches the authorized support workflow. It does not retroactively begin from the time a personal email, text message, physical letter, unrelated phone call, or other unsupported communication was originally sent.
This is not about limiting communication. It is about making sure your request is visible to the entire IT Department instead of depending on one individual person. A properly submitted request can be seen, assigned, escalated, reassigned, reported on, and continued by another qualified team member if someone is unavailable. An off-channel message may exist only on one person’s phone, inbox, voicemail, or desk.
| Using the Support Workflow Provides | Off-Channel Communication May Depend On |
|---|---|
| Department-wide visibility | One employee seeing the message |
| Automatic time stamping and tracking | Someone remembering when the communication arrived |
| Priority and business-impact review | The recipient recognizing the urgency correctly |
| Assignment to the appropriate resource | The person contacted being available and qualified for the issue |
| Escalation and reassignment | The original recipient forwarding the request manually |
| SLA and performance reporting | No reliable service-level measurement |
| Complete support history and documentation | Information being scattered across personal communications |
When you need IT assistance, use the authorized email, telephone number, IT Support Panel, support application, or other approved tool for the team you need. If the matter is urgent and you want immediate human engagement, call the appropriate Support team.
The support process protects the client. It helps make sure your request does not depend on one employee being available, remembering a conversation, checking a personal message, or manually passing information to someone else.
Requested deadlines are useful. Please tell us what you need and why the timing matters. A requested deadline helps the team understand the business need and may affect coordination, scheduling, communication, or the available solution.
It does not automatically:
Sometimes the permanent solution requires planning while an immediate business need can be handled another safe way. For example, a new remote-access method may require firewall, application, security, certificate, vendor, or infrastructure review. An existing approved remote-access method may satisfy the immediate need while the permanent change is properly scoped. This is part of good IT management: solve the business need while protecting the long-term health of the environment.
Only Response is a guaranteed time-based SLA commitment. We still publish and measure Plan and Resolution because we believe clients should have visibility into more than the minimum contractual requirement.
| Measurement | Why We Measure It |
|---|---|
| Response | Confirms that new requests are receiving timely human attention. |
| Plan | Shows whether technical engagement is beginning in a reasonable timeframe. |
| Resolution | Helps identify overall support efficiency, recurring blockers, escalation patterns, and areas for improvement. |
Transparency is the point. We measure more than the minimum time-based commitment because good IT management requires us to continually evaluate the complete support experience.
Service levels are only one part of a healthy support relationship. You should also expect:
Good service-level management is not about celebrating a timer. It is about using measurable standards to build a responsive, accountable, well-managed IT department over time.
No. The automatic confirmation proves that the ticketing system received the request. Respond Within requires human review and response.
No. Plan Within represents human technical engagement. A technical resource has reviewed the request and established or begun the next working path.
No. “Plan” is a service-management measurement. It means technical engagement has begun and the next path has been established. That path might be troubleshooting, a call, escalation, vendor involvement, scheduling, scoping, or another appropriate action. A formal project or change may later require a written scope or Change Management Request, but that is a separate process.
No. Plan Within is an operational performance target that we publish and measure for accountability and transparency. The time-based SLA commitment we guarantee is Respond Within, subject to the applicable service documents and contractual exceptions.
No. Resolution is always best effort. The Resolve Within number is an operational performance target that helps us measure how effectively tickets are moving toward completion. It cannot guarantee the outcome of an unknown technical problem.
Because it is still useful. Resolution trends can reveal recurring vendor delays, difficult technology, training needs, escalation problems, staffing pressure, aging infrastructure, or other opportunities to improve IT health. A measurement can be valuable for management without being a contractual completion guarantee.
No. Best effort recognizes that the final technical outcome may depend on factors outside the IT department’s control. We still measure resolution performance, manage the ticket, communicate, escalate when appropriate, and work toward the correct outcome.
No. The Response timeframe should be viewed as the outer service-level window under qualifying conditions, not the amount of time we expect every request to wait. Our goal is to respond sooner whenever possible, and we commonly do.
Because you were already interacting with a person. During a live support interaction, human Response and technical engagement can occur at essentially the same time.
It is a management KPI used to evaluate performance trends across qualifying tickets. It does not mean that 10% of tickets are intentionally ignored or allowed to miss their service commitment.
No. Response and Plan are initial ticket milestones. They do not create a new SLA every time another email, note, or update is added to the same request.
No. Priority is based on business impact. An owner, executive, or other important contact can receive additional visibility, communication, or coordination, but job title alone does not change the SLA priority.
Yes. Tell us what changed and explain the business impact. The support team will review the request and determine the appropriate priority.
Tell us as early as possible and explain why the date matters. A requested deadline helps us understand the business need and coordinate the work, but it does not create a guaranteed resolution deadline or automatically change the SLA priority.
The correct Plan may be to scope the work before making changes. This is not a failure to support the ticket. It is good change management. New functionality or changes involving several systems, vendors, security controls, or meaningful business risk may need to move from normal troubleshooting into a planned change or project workflow.
Tell us immediately. Reply to the existing ticket or call the Support team. The priority can be reviewed again based on the new business impact.
Call. If you want immediate human engagement, calling is the fastest support path. Email and portal submissions remain excellent options when the request can follow normal asynchronous processing.
No. A direct employee email is not automatically an authorized support request and may not enter the ticketing system. Direct communications are handled best effort until the request reaches an approved support workflow. Use the designated support email or other authorized channel for the team you need.
Only if you are using an EasyITGuys text or chat service specifically provided as an authorized support channel.
A personal text message to an individual employee does not start the SLA.
If the call does not reach the authorized support workflow, the SLA may not begin from that call.
We may help redirect the request when it is discovered, but the safest approach is to use the designated support number for the appropriate department.
Once the request is entered into the authorized support workflow, it can be prioritized, assigned, tracked, and measured normally.
The SLA begins when the request enters that workflow. It does not retroactively begin from the earlier unsupported communication.
Because the IT Department cannot reliably manage what it cannot see. An individual employee may be unavailable, off duty, on vacation, in a meeting, working another request, or simply not the correct resource for the issue. The authorized support workflow gives the entire team visibility and allows the request to be routed, escalated, measured, and managed appropriately.
No. We will make a reasonable effort to help redirect or capture the request when it is discovered. The distinction is that off-channel communications are best effort and outside the guaranteed service-level workflow until they are entered into an approved support channel.
This Client University article is an educational guide designed to help you understand our support workflow and service dashboard.
Your current Quote, Master Services Agreement / Terms and Conditions, Services Guide, approved scope of work, and other applicable written client-specific agreements determine the actual services, commitments, coverage, exceptions, and responsibilities for your organization. If a conflict exists, the applicable governing service documents control.
The goal is simple: respond reliably, engage technically, communicate clearly, resolve as efficiently as the circumstances allow, measure our performance, and keep improving your Managed IT Department over time.
