Reference · built on requestOperator by FibricFleet, routes & field

Service Window

Detects when a technician will miss a promised arrival window and proposes a new window to the customer, with a reschedule option.

Request accessPricing ↗

About

A promised window is a commitment the dispatch board cannot see slipping. Service Window reads each appointment's arrivalWindowStart, arrivalWindowEnd, and status from ServiceTitan, the technician assigned to it, and the van's position and engineState from Samsara or Geotab. When the prior job is still Working as the next window opens, or the van is too far to arrive in time, the window is at risk.

It proposes a message to the customer with a new window and the option to reschedule, and a matching change on the appointment. A dispatcher approves the message, the new window, or a reassignment to a nearer technician. Nothing is sent or moved until then.

This is a reference listing. It documents what Fibric would read from Service Window and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Appointments with arrivalWindowStart, arrivalWindowEnd, start, end, and status from ServiceTitan jpm/v2, and the technician from AppointmentAssignments_GetList in dispatch/v2
  • The van's position and engineState from Samsara through GET /fleet/vehicles/stats, or latitude, longitude, isDriving, and currentStateDuration from Geotab's DeviceStatusInfo
  • Whether the technician's current job is still Working when the next window opens, from the appointment status history
  • Housecall Pro job.on_my_way and job.started events, which say when a technician actually leaves and arrives
  • ServiceAppointment records in Salesforce Field Service with ArrivalWindowStartTime, ArrivalWindowEndTime, and scheduled and actual times, where that is your system
  • Customer replies to the window message, received through Twilio's inbound message webhook with From and Body

Proposed actions

  • Target capability: propose a Twilio message to the customer naming the new window and offering a reschedule, through the Messages resource with To and Body
  • Target capability: propose the new window on the appointment through Appointments_Reschedule in ServiceTitan jpm/v2, or a ServiceAppointment update in Salesforce Field Service
  • Target capability: propose moving the visit to a nearer technician through AppointmentAssignments_UnassignTechnicians and AssignTechnicians in dispatch/v2
  • Target capability: propose a Slack message to the dispatch channel through chat.postMessage with the van's position, the window, and the proposed change
  • Target capability: propose Appointments_Hold when the customer replies that no new window works today

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Warn a ServiceTitan customer before the window closes

    Read the appointment's arrivalWindowEnd, the van's gps from Samsara, and the prior job's status. When the van cannot arrive in time, propose the customer message and Appointments_Reschedule together for one approval.

    With ServiceTitan, Samsara, Twilio

  • Reassign to the nearer technician

    Read DeviceStatusInfo for every van on the board, find one that is stopped near the address with its next appointment later, and propose the unassign and assign pair in dispatch/v2.

    With Geotab, ServiceTitan

  • Use on-my-way events where there is no telematics

    Take job.on_my_way and job.started from Housecall Pro as the arrival signals. A job that starts after its window ends is logged, and the next customer on the route gets a proposed message.

    With Housecall Pro, Twilio

  • Keep dispatch in the loop

    Every proposal is mirrored as a Slack message in the dispatch channel with the van, the window, and the change, so the dispatcher sees what the customer will read before approving.

    With Slack

Requirements

  • A field service system that exposes arrival windows by API: ServiceTitan, Housecall Pro, or Salesforce Field Service
  • Telematics on the technicians' vans: Samsara or Geotab, with the vehicle mapped to the technician's record
  • A Twilio number or Messaging Service whose inbound message URL points at the reply receiver
  • The travel-time margin and the earliest warning time you accept, set per business unit
Authentication
ServiceTitan OAuth 2.0 client credentials sent with an ST-App-Key header, a Samsara API token with Read Vehicle Statistics or a MyGeotab API user, a Twilio Account SID and auth token, and a Slack app with chat:write.

Limits

  • Arrival is estimated from position and the remaining job; the job does not know how long a repair will run
  • A van with no gateway, or a technician driving a personal vehicle, gives no position and is not watched
  • Samsara notes the Vehicle Locations API is older than the stats feed; the job reads gps from the stats feed instead
  • The customer is messaged only after a person approves; a window that recovers before then is dropped without contact

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Service Window ↗

Questions and answers

What exactly does the dispatcher approve?
A paired proposal: the text the customer will receive, with the new window written in, and the appointment change behind it. Approving one without the other is allowed. A reassignment shows the technician being removed and the one being added.
Where is the evidence that the window was really at risk?
On the entry for that appointment: the van's position and time, the distance to the address, the prior job's status, the window as promised, and the window proposed. If the customer replied, the reply is attached. The dispatcher's decision and time close the entry.
Does it ever text the customer without approval?
No. It drafts. Twilio sends only after a dispatcher approves, and each appointment gets at most one message per proposal. If the risk clears while the proposal is waiting, the proposal is withdrawn and the entry says so.
Ask about Service Window

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy