Support Deadlines: Which Clock Should Your Helpdesk App Count?

Before putting a countdown on support requests, define the promise it measures. “Respond within working hours” is incomplete without a target event, a start point, a calendar and any permitted pauses. A colourful deadline can be precise-looking while measuring the wrong thing.

This is software planning guidance, not a recommended contractual response time. Agree customer commitments and any legal implications separately with the appropriate advisers.

Name what must happen before the deadline

An acknowledgement, a substantive first response, work starting and an issue being resolved are different targets. An automatic receipt should not satisfy a promise of human investigation unless that is genuinely what your published policy says.

The Odoo 19 SLA guide defines a target as the stage a ticket must reach and the time allowed to reach it. That is a product-specific mechanism, not evidence that every status change represents the quality of response your customers expect. In your app, define the qualifying action and the evidence staff must record.

Also specify which requests are covered. Team, customer agreement, service and priority can affect the applicable rule. Do not make an urgent label alone create a promise the business has not approved. Show a request with no matching policy as uncovered, not as successfully on time.

Give the clock an explicit start and calendar

Choose whether timing begins when the request is received, created in the helpdesk or accepted after an agreed intake check. If these moments differ, retain enough information to explain the result. Importing an old request should not quietly make it look newly received.

Odoo documents calculating a deadline from ticket creation and targeted working hours once a policy's criteria apply. For a custom implementation, ask what happens when priority or policy changes later. Does the target still refer to the original start, or is a new target created? Do not let a routine edit erase a missed deadline without explanation.

Name the working calendar, its time zone, holidays and exceptional closures. Elapsed time and business time are different measurements. Test out-of-hours intake and a calendar change rather than inferring the result from the label “one business day”. No universal duration is recommended here.

Pause only for the reasons you actually allow

Decide whether waiting for customer information, a supplier or an internal colleague pauses a particular target. Those reasons are not interchangeable. Odoo supports excluding configured stages from its deadline calculation, but the source does not decide which pauses are appropriate for your service.

Require a recorded reason and an authorised transition. A request must not stop consuming target time merely because nobody has picked it up. Decide what a customer reply does to a permitted waiting pause and what happens if staff apply the waiting status after the target was already missed.

Pause and resume behaviour should be demonstrable from the timeline. Avoid a report that shows only the final adjusted number with no explanation of the excluded periods.

Finishing late is still different from meeting the target

A request can be solved after its deadline. Keep the completion outcome separate from whether the target was met. Odoo illustrates this by retaining its failed SLA indicator after the target stage is reached late.

For your reports, distinguish active, met, missed and not-covered targets as appropriate. If one request has several targets, label which is displayed and preserve each outcome. Reopening, corrections and policy revisions need explicit rules rather than silently improving historical performance.

Ask for a timed walkthrough

Use synthetic requests and controlled test times in the acceptance criteria: intake outside working hours, a holiday, a permitted pause, a reply that resumes the clock, a priority change and late completion. Include an uncovered request and a request with more than one target.

Compare the visible deadline, event timeline and report. Staff should be able to explain the counted time without reverse-engineering a colour. For a helpdesk app discussion, bring the actual support policy first. The countdown should implement that policy, not invent it.