The SLA engine

GVenta Help Desk measures every ticket against two service-level targets, one for first response and one for resolution, and it measures them in business time, not wall-clock time. This page explains the targets, the working calendar, how deadlines are calculated and how compliance shows up in reports.

Targets by priority

Each priority has a first-response target and a resolution target, expressed in minutes of business time. The shipped defaults are:

Priority	First response	Resolution
Urgent	30 minutes	240 minutes (4 business hours)
High	120 minutes (2 business hours)	1,440 minutes (24 business hours)
Medium	480 minutes (8 business hours)	2,880 minutes (48 business hours)
Low	1,440 minutes (24 business hours)	10,080 minutes (168 business hours)

Targets are edited under Settings → SLA & Reports, which is visible to Super Admins only. Updates validate the priority values and enforce a one-minute minimum.

The working calendar

Business hours

Business hours are a timezone plus, for each weekday, an enabled flag and open and close times. The default is Monday to Friday, 09:00 to 17:00, America/New_York. The timezone is validated against the system’s timezone list when saved.

Holidays

Holidays are named non-working dates. Any date on the list is excluded from SLA timers entirely. Holidays are added individually and deleted individually.

Why it matters: An SLA clock that respects your actual working week. A ticket raised at 4:55pm on the Friday before a public holiday isn’t quietly breached over a weekend nobody was working.

How deadlines are calculated

Deadlines are computed when the ticket is created, not when a report runs. At creation, the application loads the SLA policy for the ticket’s priority and hands the two minute budgets to a business-hours calculator, which converts each into an absolute timestamp. The results are stored on the ticket as first_response_due_at and sla_due_at.

The calculator walks forward from the creation time, consuming only minutes that fall inside a configured working window and skipping:

• non-working hours,
• disabled weekdays, and
• configured holidays,

all evaluated in the configured timezone.

Two safety measures are built in:

• A 24/7 fallback. If no working days are configured at all, the calculator degrades to a plain around-the-clock calculation, so SLAs never silently vanish because of a misconfiguration.
• A loop guard, so a pathological configuration cannot hang the calculation.

Every channel gets the same treatment. Tickets raised by email, through the client portal or via the API all pass through the same creation path, so they all receive business-hours deadlines.

Why deadlines are stored rather than computed

Because the deadlines are absolute values on the ticket record, reporting is a simple indexed comparison rather than a recursive calendar calculation across every ticket in the range. That is what keeps SLA reporting fast at scale.

When the clock stops

first_response_at is stamped automatically on the ticket the first time an agent sends a reply. resolved_at is set when the ticket is resolved. Compliance is judged by comparing these actual timestamps against the stored deadlines.

SLA in reports

The Overview tab of Reports and analytics contains two SLA compliance panels, one for resolution SLA and one for first-response SLA. Each shows:

• total tickets measured,
• how many met the target,
• how many breached, and
• a compliance percentage.

Compliance is calculated by comparing sla_due_at and first_response_due_at with the actual resolved_at and first_response_at values. Still-open tickets that have already passed their deadline count as breached, so the panel never flatters you by ignoring work that is currently late.

All of the shared report filters (status, priority, source, agent, customer) and the date range apply to the SLA panels, and the CSV export uses the identical filter set as the on-screen report.

Elsewhere in the application:

• The dashboard’s My Overdue and Overdue figures are built on the same deadlines and drill straight through to the tickets that produced them. See Dashboard.
• The ticket list API accepts date_field=sla_due_at alongside date_from and date_to, so an integration can ask for everything due in a window. See the tickets group of the endpoint reference.

Emailed digests

Under Settings → SLA & Reports you can also enable emailed report digests:

• a weekly digest, sent on Mondays, and/or
• a monthly digest, sent on the 1st of the month,

with a free-text recipient list. Each digest is an Overview report delivered as an HTML summary with a CSV attachment. Digests are sent by the background jobs described in Background jobs and workers, using the active outgoing email provider.

Configuring the SLA engine

Everything on this page is administered from Settings → SLA & Reports, and the same settings are available through the API:

• GET /api/sla-settings returns policies, business hours, holidays and digest configuration in one call.
• PUT /api/sla-policies updates per-priority targets.
• PUT /api/sla/business-hours sets the timezone and per-weekday windows.
• POST /api/sla/holidays and DELETE /api/sla/holidays/{id} manage holidays.
• PUT /api/sla/digest configures the digests and their recipients.

The write endpoints require a Super Admin. Full details are in the endpoint reference.