Support First Response Business Hours Report

Calculate first-response business duration and declared-target due dates from a normalized ticket export and a finite set of working intervals. Use it for a weekly spreadsheet handoff, a consultant review, or checking how a changed working calendar affects a supplied batch. Each ticket includes the exact calendar segments consumed, source references, response-observation status, and a target classification.

Zendesk and Freshdesk already provide business-hour metrics and policies. This Actor is useful when you need a portable calculation and evidence report from authorized exports. It does not connect to either service or reproduce their channel-specific, automation, solved-ticket, or advanced SLA rules. You decide which response qualifies as the first reply before uploading the data.

Prepare the input

Supply snapshotId, an explicit asOf timestamp, responseObservation, schedules, and both input tables. tickets contains sourceId, ticketId, createdAt, firstReplyAt, scheduleId, and targetMinutes. Use literal string IDs so values such as 0001 retain their zeros. firstReplyAt must be an explicit instant or JSON null; target minutes must be a positive integer between 1 and 525,600. Creation and reply cannot be after asOf, and reply cannot precede creation.

Each schedule declares scheduleId, coverageStart, coverageEnd, and coverage: complete, incomplete, or unknown. workIntervals contains scheduleId, intervalId, start, and end. Expand weekdays, split shifts, holidays, and daylight saving changes yourself. All dates require seconds and Z or a known numeric RFC3339 offset; local timestamps, unknown -00:00 offsets, leap seconds, and precision beyond milliseconds are rejected. Output instants use UTC.

Intervals are half-open [start,end), must remain inside the schedule's coverage bounds, and cannot overlap. Adjacent intervals are allowed. Duplicate schedule IDs, duplicate sourceId plus ticketId, and duplicate schedule plus interval IDs are rejected, including identical duplicates. Deduplicate the export intentionally before submission; the Actor never chooses a winning duplicate silently.

For responseObservation, declare from, through, and coverage. These boundaries are inclusive and apply to all supplied ticket sources. complete means you assert that the supplied first reply, or its absence, is fully observed over that period. Both response observation and the calendar must be complete over creation through the measured endpoint before the report reaches a target conclusion. In a complete calendar, time without a supplied interval is non-working. In an incomplete calendar, that omission cannot establish a closure.

Understand the result

An answered ticket consumes working time between creation and its supplied first reply. A ticket without a reply consumes working time through asOf. An answered duration equal to the target is answered_within_target. A missing response at equality is pending_at_target; only a strictly greater duration is pending_after_target.

observedBusinessMilliseconds, seconds, and minutes show supplied interval intersections even when evidence is partial. measuredBusinessMilliseconds is null when calendar coverage does not establish the whole duration. classification is unresolved when calendar or response coverage is insufficient. A blank reply does not prove lateness without complete response observation. Unknown due dates are separate from response conclusions: an already answered ticket can have a measured duration while its longer target falls beyond the supplied future calendar. The Actor never invents future work intervals.

The sample shows a ticket created at 17:30 and answered at 09:30 the next working day. With shifts from 09:00 to 18:00, it consumes 60 business minutes and meets a 60-minute target exactly. It also includes an answered-after-target ticket and pending tickets below, at, and above their target.

CSV and downloads

Instead of either array, remove that array and provide its nonempty CSV alternative: ticketsCsv or workIntervalsCsv. Canonical headers are the field names above. ticketColumns and intervalColumns can map every canonical field to a distinct header; no extra columns are accepted. csvDelimiter supports comma, semicolon, or tab. BOMs and quoted fields are accepted; duplicate headers, irregular rows, and noncanonical integer targets are rejected. An empty first-reply CSV cell means null; header-only CSV means an explicitly empty table.

The dataset contains one complete report. Download OUTPUT JSON, flat evidence.csv, review findings.csv, and standalone report.html. JSON retains all calendar sources and interval traces. CSV includes interval arrays as JSON cells and neutralizes formula prefixes. HTML escapes identifiers, has no scripts or external assets, and should be downloaded before opening locally.

Price, limits, and privacy

The intended price is $0.25 per completed report, with platform usage included. There is no startup fee or additional dataset-item fee. Invalid input, insufficient report budget, and output-cap failures produce no report event. Resuming the same run restores exports and keeps one report and one charge; a new run is a new billable report. An interrupted export may leave partial uncharged files until the same run resumes. If delivery or billing state is inconsistent, recovery refuses to guess.

Limit each input to 4 MB, 100 schedules, and 5,000 combined ticket and interval rows. Reports support at most 10,000 combined measured and due-date evidence segments, JSON below 8 MB, and each export below 9 MB; split a batch if one of those bounds is exceeded. An empty ticket table produces an unresolved summary and provides no evidence about tickets absent from the export. All findings require human review and are conditional on your supplied coverage assertions. This is not legal SLA certification, employee ranking, alerting, or a source-system update.

Use authorized exports and opaque identifiers; do not include names, email addresses, message bodies, credentials, or confidential content unnecessary for the calculation. Apify retains the cloud run's input and results under your account and platform retention settings. The Actor makes no external requests and does not use paid AI APIs.