How SLA Tiers Work in Regentra PSA

A plain-language guide to how SLA tiers are structured in Regentra — what they control, how the clock works, and how to configure them so tickets are managed consistently from day one.

‍

What an SLA tier is in Regentra

An SLA tier in Regentra is a set of time-based targets that define how quickly a ticket at a given priority level must be responded to and resolved. When a ticket is created, Regentra assigns it a priority — Critical, High, Medium, or Low — and the SLA policy attached to that client starts a clock for both the first response and the resolution deadline.

SLA tiers exist to give your technicians clear, visible targets on every ticket and to give you a consistent way to measure whether service delivery matches what you have committed to in your client agreements. Every ticket in the service desk is working against an SLA clock the moment it is created. Nothing sits in a queue without a deadline attached to it.

How the SLA clock works

Regentra runs two separate clocks on every ticket: a response clock and a resolution clock.

Response clock

The response clock starts the moment a ticket is created — whether submitted by the client through the portal, received by email, or opened manually by a technician. It stops when a technician posts the first substantive reply to the ticket. An automated acknowledgment does not stop the response clock. Only a human response that demonstrates the ticket has been seen and is being worked on counts as a first response.

Resolution clock

The resolution clock also starts at ticket creation and stops when the ticket is moved to a closed status. It measures the total elapsed time from when the issue was reported to when it was confirmed resolved. The resolution clock runs continuously unless a pause condition is met — more on that in the pause rules section below.

Both clocks are visible on every ticket in the technician view. The time remaining against each target is displayed in real time, color-coded to show normal status, approaching deadline, and breached. Technicians do not need to calculate or remember deadlines — the platform shows them at a glance on every ticket they are working.

Important distinction: SLA clocks run against business hours, not calendar time — unless a ticket's SLA policy is configured for 24/7 coverage. A Critical ticket created at 5:00 PM on a Friday does not consume its full response window over the weekend if business hours are set to Monday through Friday. Configuring business hours accurately is essential for SLA targets to be meaningful.

Priority levels and what they mean

Every ticket in Regentra is assigned one of four priority levels. Priority determines which SLA tier applies and sets the response and resolution targets the ticket is measured against.

• Critical — business operations are stopped or severely impaired. A user or group of users cannot perform core work functions. This priority carries the shortest response and resolution targets and triggers the most aggressive escalation rules.
• High — a significant impact on one or more users, but a workaround may exist or the issue is isolated to a subset of the organization. The situation requires prompt attention but is not a complete stoppage.
• Medium — a moderate impact with a functional workaround available. The affected user or system can continue operating while the issue is addressed. This is the most common priority level for general service requests and non-urgent issues.
• Low — no immediate operational impact. The request can be addressed during normal workflow without urgency. Examples include software update requests, scheduled configuration changes, and informational inquiries.

Priority can be set manually by the technician at intake, assigned automatically by an automation rule based on ticket category or source, or adjusted at any point during the ticket lifecycle if circumstances change. Changing a ticket's priority updates the active SLA targets immediately — the clocks recalculate against the new tier from the point of the change.

SLA policies and how they are applied

An SLA policy is the full configuration that defines how SLA tiers behave for a given client or service tier. It contains the response and resolution time targets for each priority level, the business hours schedule the clocks run against, the pause rules that stop the clock in specific conditions, and the escalation rules that fire when targets are approached or missed.

Regentra comes with a default SLA policy that applies to all clients unless a specific policy is assigned. The default policy is a reasonable starting point, but most MSPs create at least two or three policies to reflect the different service tiers in their client contracts — a premium policy for clients with faster response commitments, a standard policy for the majority of the portfolio, and potentially a custom policy for clients with unusual requirements.

Policies are created and managed under the SLA Policies section in the PSA configuration settings. Once created, a policy is assigned to a client from the client's configuration page. All new tickets for that client automatically inherit the assigned policy. Changing a client's policy applies to new tickets only — tickets already in progress retain the policy that was active when they were created.

Business hours and how they affect SLA timing

Business hours tell Regentra which hours of the day and which days of the week to count toward SLA clocks. If your team operates Monday through Friday from 8:00 AM to 6:00 PM, configuring those hours means SLA targets only consume time during those windows — a ticket created at 5:45 PM on a Thursday only uses fifteen minutes of its SLA window that evening, and the clock picks up again at 8:00 AM Friday.

Business hours are configured per SLA policy, not globally. This means a client with a 24/7 support agreement can be on a policy with around-the-clock SLA coverage while standard clients run business-hours-only clocks — all within the same platform, without any manual time adjustment required.

Public holidays and scheduled closures can be added to a business hours configuration so that SLA clocks do not run on days your team is not operating. Failing to configure holidays means SLA targets continue to consume time on days when no one is working, which inflates breach rates artificially and gives an inaccurate picture of team performance.

When the SLA clock pauses

The resolution clock does not run continuously in all circumstances. Regentra supports SLA pause rules — conditions under which the resolution clock stops and does not resume until the condition is cleared. Pause rules reflect the reality that not all time in a ticket's lifecycle is time the MSP is actively responsible for.

The most common pause condition is waiting for client response. When a technician has asked the client a question or is waiting on information, access, or a decision from the client's side, the ticket can be moved to a waiting status. If the SLA policy includes a pause rule for the waiting status, the resolution clock pauses at that point and restarts when the technician moves the ticket back to an active status.

Other common pause conditions include:

• Waiting for vendor — the resolution depends on action from a third-party vendor, supplier, or carrier outside the MSP's control.
• Scheduled maintenance — the resolution requires a maintenance window that has been agreed with the client and is not yet open.
• On hold by client request — the client has asked to defer resolution to a specific date or time.

Pause rules are configured within each SLA policy. A status can only pause the clock if it is explicitly included as a pause condition in the active policy — moving a ticket to a waiting status in a policy that has no pause rules configured will not stop the clock. Confirm your pause rules are set up correctly before going live with any new SLA policy.

Why pause rules matter: Without pause rules, technicians have a practical incentive to close and reopen tickets rather than use waiting statuses accurately — because leaving a ticket in waiting status with a running clock creates artificial breaches. Accurate pause rule configuration makes honest status updates the right behavior, which keeps your SLA data clean and your ticket history reliable.

Breach alerts and automatic escalation

Regentra sends automated alerts as SLA deadlines approach and fires escalation actions when deadlines are missed. Both are configured within the SLA policy and run without any manual intervention once set up.

Approaching deadline alerts

Pre-breach alerts notify the assigned technician when a ticket has used a defined percentage of its SLA window. A common configuration sends an alert at 50% and again at 75% of the response or resolution target. These alerts are a prompt — not an alarm — that give the technician time to update the ticket, request more information, or escalate before a breach occurs rather than after.

Breach notifications

When a response or resolution target is missed, Regentra records the breach against the ticket and sends a breach notification to the configured recipients — typically the assigned technician and a team lead or account manager. The breach is logged in the ticket's activity history with a timestamp and remains visible in SLA reporting even if the ticket is subsequently resolved.

Automatic escalation

SLA policies in Regentra can be configured to automatically escalate a ticket at the point of breach — reassigning it to a senior technician, a team lead, or a designated escalation queue. Automatic escalation removes the dependency on someone noticing that a deadline has passed and manually intervening. Once configured, it fires on every breach, every time, without exception. This consistency is what makes escalation rules operationally meaningful rather than aspirational.

Applying different SLA policies per client

Different clients have different service agreements, and Regentra is designed to reflect that without requiring manual workarounds. Each client in your portfolio can be assigned a distinct SLA policy — a premium client on a two-hour Critical response gets a different policy than a standard client on a four-hour response, and the platform enforces both simultaneously without any overlap or confusion between client environments.

To assign a policy to a client, navigate to the client's configuration settings in the PSA, locate the SLA policy selector, and choose the appropriate policy from the list of configured policies. The assignment takes effect immediately for all new tickets raised under that client. If you need to change a client's policy — after a contract renewal or service tier change, for example — update the assignment in the same location. Existing open tickets retain their original policy; new tickets use the updated one.

For clients whose contracts include terms that do not fit any of your standard policies, create a dedicated policy for that client before assigning it. A client-specific policy is not an unusual configuration — it is the correct approach for any client with materially different service commitments than your standard tiers.

Where to see SLA status on a ticket

SLA status is visible directly on every ticket in the technician view. The ticket header displays the current response and resolution time remaining, updated in real time. The display uses color coding to communicate urgency at a glance:

• Standard color — the ticket is within its SLA window with comfortable time remaining.
• Amber — the ticket is approaching its deadline. A pre-breach alert has been or is about to be triggered.
• Red — the SLA has been breached. The ticket is past its response or resolution target.

In the ticket queue view, the same color coding applies to the SLA column, giving technicians an instant read on which tickets need attention without opening each one individually. Sorting the queue by SLA status surfaces the most time-sensitive tickets at the top, which is the recommended default queue view for service desk teams managing high ticket volumes.

SLA performance across all tickets — compliance rates, breach counts, average response and resolution times — is available in the PSA Reports section. Reports can be filtered by client, by priority level, by technician, and by date range, giving you the data needed to review performance with clients at quarterly business reviews and to identify any priority levels or client environments where breach rates are consistently above target.

SLA tiers in Regentra are designed to be visible without being intrusive and enforced without requiring manual oversight. Once the policies are configured correctly — with accurate business hours, appropriate pause rules, and escalation triggers in place — the platform manages the clock so your technicians can focus on resolving the ticket rather than tracking the deadline themselves.

‍