.jpg)
SLA reporting and SLA management are two different things, and most operations teams are only doing one of them. Reporting means calculating compliance after tickets are closed and presenting the numbers in a monthly review. Management means knowing, while a ticket is still open, whether it is on track to meet its commitment or whether it is already heading toward a breach.
The gap between the two is almost always a data timing problem. The fields needed to calculate SLA compliance, fault start time, committed resolution time, actual close time, all exist in the ticketing system. But they are only queryable together once the ticket is closed. While the ticket is open and a breach is still preventable, there is no live indicator showing how long it has been active or how close it is to the ETR commitment.
This guide covers how to close that gap in a Clappia-based ticketing app by configuring two complementary time metrics: a live ticket age formula that updates every time the record is opened, and a total restoration time formula that calculates the definitive duration once the ticket is closed. Together they give your operations team a complete picture: real-time visibility while tickets are active, and accurate historical data for SLA reporting once they are resolved.
It is worth being explicit about why you need two separate formulas rather than one. The distinction matters both for how you build them and for how your team uses them.
| Metric | What It Measures | When It Is Used | Updates? |
|---|---|---|---|
| Ticket Age (Live) | Time elapsed since the ticket was created | While the ticket is open and active | Every time the record is opened |
| Total Restoration Time | Total hours from fault start to confirmed close | After the ticket is closed for reporting | Static once fault close time is entered |
Ticket Age is a live indicator. It tells the NOC team and field engineers how long a ticket has been sitting without resolution. Because it uses the current time in its calculation, it refreshes every time someone opens the record. An engineer looking at a list of open tickets can immediately see which ones have been aging the longest and prioritise accordingly.
Total Restoration Time is a closed-ticket metric. It uses the actual fault start time and the actual fault close time to compute the definitive hours taken to restore service. This is the number that feeds your mean time to repair calculations, your SLA compliance percentages, and your contractual reporting. It is fixed the moment the fault close time is entered and does not change after that.
Live aging tells you what needs attention right now. Total restoration time tells you how well you performed. You need both to manage SLA proactively rather than just reporting on it retrospectively.
Both formulas depend on underlying date and time fields being present and correctly configured in your ticketing app. Before adding any formula blocks, make sure the following fields exist:
Submission Created Time
This is the timestamp anchor for the live Ticket Age formula. Add a Date/Time block labelled 'Submission Created Time'. Set it to auto-capture the current date and time when the form is opened, and make it read-only so it cannot be edited after the ticket is created. This field should be hidden from the main form view since it is a system anchor rather than a user-facing input. Its only job is to give the Ticket Age formula a fixed starting point.
Fault Start Date and Fault Start Time
These capture when the actual fault began, which is often different from when the ticket was created. An alarm may have been active for twenty minutes before an engineer opened the ticketing app. Add a Date block labelled 'Fault Start Date' and a Time block labelled 'Fault Start Time'. Both are user-entered and should be required fields, since they are the denominator of your Total Restoration Time calculation.
Fault Close Date and Fault Close Time
These are the numerator of Total Restoration Time. Add a Date block labelled 'Fault Close Date' and a Time block labelled 'Fault Close Time'. These fields are filled in by the field engineer or NOC analyst when service is confirmed restored. They should only become required when the ticket status reaches 'Restored' or 'Ticket Closed', which you can enforce using a Validation block with a condition that checks both the status and whether these fields are empty.
Committed ETR Date and Committed ETR Time
These record the promised restoration time, distinct from the initial estimated time of resolution category. Add a Date block labelled 'Committed ETR Date' and a Time block labelled 'Committed ETR Time'. These are updated during the incident as commitments are revised, giving you a record of what was promised at closure time even if the original ETR category was changed mid-incident.
With the Submission Created Time field in place, you can build the live aging indicator. Add a Formula block labelled 'Ticket Age'. In the formula editor, type @ to insert field variables; Clappia shows a list of all fields in your app and wraps the selected name in curly brackets automatically.
The formula calculates the difference between now and the submission created time, then formats it as hours and minutes:
TEXT(INT((NOW()-{Submission Created Time})*24),"0") & " Hrs " & TEXT(INT(MOD((NOW()-{Submission Created Time})*24*60,60)),"0") & " Min"
Fields used: Submission Created Time.
What the formula does: Subtracts the submission created timestamp from the current time to get the elapsed duration as a decimal day value. Multiplying by 24 converts it to hours. The INT function extracts the whole hours. MOD extracts the remaining minutes by calculating the remainder after dividing total minutes by 60. TEXT formats each component as a clean number string.
What the user sees: A read-only field showing something like '7 Hrs 23 Min'. Every time the record is opened or refreshed, this value recalculates to reflect the current elapsed time. An open ticket list sorted by Ticket Age immediately shows which incidents have been active the longest.
A practical note on display: keep the Ticket Age field visible on the main ticket view at a prominent position, near the top of the Details section rather than buried at the bottom. Its value is most useful when the person reviewing the ticket sees it before they see anything else. The Submission Created Time field itself can remain hidden since it serves purely as the calculation anchor.
The second formula calculates the definitive time taken to resolve the fault, from when the fault actually started to when it was confirmed closed. This is a different measurement from Ticket Age because it uses the actual fault start time rather than the ticket creation time, and it produces a static result rather than a live counter.
Add a Formula block labelled 'Total Time Spent on Fault Rectification (Hours)'. The formula:
(({Fault Close Date}-{Fault Start Date})*24)+(({Fault Close Time}-{Fault Start Time})*24)
Fields used: Fault Close Date, Fault Start Date, Fault Close Time, Fault Start Time.
What the formula does: Calculates the day difference between close and start dates and multiplies by 24 to get hours. Then calculates the time difference in the same day and adds the two components together. This correctly handles faults that span midnight, because the date component captures the full day gap while the time component captures the partial-hour offset.
What the user sees: A read-only numeric value such as '4.75', representing 4 hours and 45 minutes of total restoration time. This value is stored permanently with the closed ticket and is the figure used in SLA compliance calculations, mean time to repair averaging, and contractual reporting exports.
One important configuration note: this formula will return an incorrect value if either the fault close date or fault close time field is empty. Add a display condition on the formula field so it is only visible when both Fault Close Date and Fault Close Time are populated. This prevents a partially filled ticket from showing a misleading restoration time.
The Estimated Time of Resolution category (1 hour, 2 hours, 4 hours, and so on) set at ticket creation gives the initial response commitment. But in practice, ETR commitments are often revised during longer incidents as the fault complexity becomes clearer. The Committed ETR Date and Time fields capture the final commitment at the point of closure, which is the more contractually significant figure.
To make ETR promise tracking meaningful in your data, you need to be able to compare three things for each closed ticket:
Together these three data points let you answer the questions that matter most in an SLA review: did we meet our initial commitment, did we meet the revised commitment, and where the answer to either question is no, how far over did we run and on what fault types?
You do not need a separate formula to compare ETR to actual restoration time. The comparison is a reporting layer operation, whether done in Clappia's analytics view or in an external tool. What matters is that all three values are stored in every closed ticket so the comparison can be made.
The formulas and ETR fields are only fully useful when they sit inside a well-defined ticket status lifecycle. The status field is what makes each ticket's position in the resolution process visible at a glance and what enables workflow-based alerting when tickets age past defined thresholds.
A practical status progression for field operations ticketing looks like this:
| Status | What It Means | SLA Relevance |
|---|---|---|
| Ticket Created | Fault logged, notifications sent | Clock starts. Ticket Age begins accumulating. |
| Ticket Assigned | Responsibility confirmed, response team identified | Assignment lag visible from Ticket Age at this status. |
| Accepted | Field engineer has acknowledged and is en route or on site | Response time measurable from Created to Accepted. |
| Active | Fault investigation and repair in progress | Bulk of resolution time typically spent here. |
| Restored | Service confirmed restored, closure documentation pending | Restoration time calculable. Close date/time should be entered here. |
| Ticket Closed | All documentation complete, ticket locked | Total Restoration Time formula finalised. Ticket Age no longer relevant. |
Two things in this lifecycle deserve particular attention from an SLA tracking perspective.
First, the transition from 'Ticket Created' to 'Ticket Assigned' should happen automatically and quickly. An auto-assignment workflow that updates the status to 'Assigned' within 60 seconds of ticket creation ensures that the assignment lag is negligible and does not artificially inflate Ticket Age for tickets that are actually being actioned. If your workflow is configured to auto-assign, the status moves to Assigned before most engineers have finished reading the Telegram notification.
Second, the fault close date and time should be entered when the ticket reaches 'Restored', not when it reaches 'Ticket Closed'. Restoration and documentation are two separate activities. The fault is restored when service is back. Documentation may take another hour. Using the Restored status transition as the trigger for entering the close timestamp keeps your restoration time figures honest.
A Total Restoration Time formula is only meaningful if the fault close date and time it depends on cannot be changed after the fact. In Clappia, you can prevent further edits once a ticket reaches 'Ticket Closed' by adding a Validation block with a condition that fires when the status equals 'Ticket Closed' and the user attempts to save any change.
The validation message can read something like: 'This ticket has been closed and cannot be edited. Contact your administrator if a correction is required.' This preserves the integrity of closed ticket data and prevents the Total Restoration Time from being retroactively adjusted in ways that distort your SLA figures.
The two formulas and the status lifecycle create a set of data points that support several monitoring and reporting views. Here are the most practically useful ones to build, whether inside Clappia's analytics view or in an external reporting tool connected via data export.
Open Ticket Age Distribution
Filter all submissions where Status is not 'Ticket Closed'. Group by Ticket Age in brackets: under 2 hours, 2 to 4 hours, 4 to 8 hours, over 8 hours. This gives your NOC team a real-time view of how many open tickets are in each aging bracket and flags which ones are approaching or exceeding their ETR commitments. This view is most useful as a live dashboard that the NOC team has open throughout the shift.
SLA Compliance by Fault Type
Filter closed tickets and cross-reference Total Restoration Time against the initial ETR category. For each fault type (by Fault Category or Fault Sub-Category), calculate what percentage of tickets were resolved within their ETR commitment. This is the core SLA compliance metric and is the one most likely to appear in client-facing or leadership-facing reports.
Mean Time to Repair by Fault Category
Average the Total Restoration Time field across closed tickets, grouped by Fault Category. This tells you which fault types take the longest to resolve and where your response process has the most room for improvement. Compare this to the ETR commitments your team sets at ticket creation to see where you are consistently over or under estimating complexity.
ETR Promise Accuracy
For each closed ticket, compare the initial ETR category to the Total Restoration Time. A ticket with an ETR of 4 hours and a restoration time of 3.5 hours is a kept promise. A ticket with an ETR of 4 hours and a restoration time of 9 hours is a broken one. Tracking promise accuracy by fault type, region, and engineer over time is one of the most actionable outputs your SLA data can produce.
Escalation Alerting on Aging Thresholds
While Clappia's workflow engine does not have a native scheduled trigger that fires based on elapsed time without a user action, you can approximate threshold alerting by extending the on-edit workflow. When a ticket is updated and the Ticket Age formula value exceeds a threshold you define in the condition logic, an additional email or Telegram notification can fire to escalate the ticket to a senior contact. The condition in the workflow would check whether the Ticket Age calculation result indicates the ticket has been open beyond an acceptable duration.
SLA tracking data is most useful when the people who need to act on it can see it wherever they are. In Clappia, access is managed at the app level under 'Manage Users'.
The Clappia mobile app on Android and iOS is where most field engineers interact with tickets. The Ticket Age formula recalculates correctly on mobile when the record is opened, so engineers on site can see how long a ticket has been active before they start their repair work. Offline mode allows fault start times and close times to be entered without a signal, with the data syncing when connectivity is restored. Given that fault sites often have degraded connectivity, this matters more for SLA data accuracy than it might seem: a close time entered offline and synced ten minutes later is still accurate. A close time entered two hours later because the form was unavailable without signal is not.
SLA management in field operations comes down to knowing two numbers at the right time. How long has this ticket been open? How long did that ticket take to resolve? The first number drives in-shift decisions about prioritisation and escalation. The second drives monthly reporting, contract reviews, and process improvement.
Both numbers come from formulas that are straightforward to configure in Clappia once the underlying date and time fields are in place. The Ticket Age formula gives live visibility. The Total Restoration Time formula gives historical accuracy. The Committed ETR fields add promise tracking. The status lifecycle ties everything together by making the ticket's position in the resolution process visible to everyone involved.
The version of SLA tracking described here does not require a dedicated SLA management tool or a complex integration. It runs inside the same ticketing app your field teams are already using, on the same mobile device they carry to every fault site. The investment is a few formula fields and a well-defined status lifecycle. The return is the ability to manage SLA performance in real time rather than discovering breaches after the fact in a monthly report.
L374, 1st Floor, 5th Main Rd, Sector 6, HSR Layout, Bengaluru, Karnataka 560102, India
3500 S DuPont Hwy, Dover,
Kent 19901, Delaware, USA
.svg){kind=small}
3500 S DuPont Hwy, Dover,
Kent 19901, Delaware, USA
L374, 1st Floor, 5th Main Rd, Sector 6, HSR Layout, Bengaluru, Karnataka 560102, India
.png)
