Every evening the job reads tomorrow's appointments from your field service system: in ServiceTitan the start, arrivalWindowStart, arrivalWindowEnd, status, and isConfirmed on each appointment; in Housecall Pro the scheduled jobs and their appointments; in Jobber the visits. It looks up the customer's mobile number on the CRM contact and drafts one reminder per visit.
You approve the batch before Twilio sends anything. Replies come back through the inbound message webhook. A reply that confirms becomes a proposed confirmation on the appointment. A reply that asks to move becomes a proposed reschedule or hold for the scheduler. Visits with no reply by the cutoff you set are listed for a person to call.
This is a reference listing. It documents what Fibric would read from Appointment Reminder 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
Tomorrow's appointments from ServiceTitan through Appointments_GetList in jpm/v2, with start, arrivalWindowStart, arrivalWindowEnd, status, isConfirmed, jobId, and customerId
Scheduled jobs and appointments from Housecall Pro through GET /jobs and the job.scheduled webhook, and visits from Jobber's GraphQL schema
The customer's phone and mobilephone properties on the HubSpot contact, read by email through GET /crm/v3/objects/contacts/{email}?idProperty=email
Delivery status per message from Twilio's StatusCallback: queued, sent, delivered, undelivered, or failed
Inbound replies from Twilio's message webhook, with From, To, Body, and MessageSid, matched to the reminder they answer
Which appointments already carry a confirmation, so a confirmed visit is not reminded twice
Proposed actions
Target capability: propose the reminder batch as Twilio messages through POST /2010-04-01/Accounts/{AccountSid}/Messages.json, with To, Body, and a StatusCallback URL
Target capability: propose a confirmation on the ServiceTitan appointment through Appointments_Confirm when the customer's reply says yes
Target capability: propose Appointments_Reschedule or Appointments_Hold when the reply asks to move, with the customer's words attached for the scheduler
Target capability: propose a Housecall Pro appointment update or a Jobber visit mutation for the same outcome on those systems
Target capability: propose a Slack message to the scheduling channel through chat.postMessage listing visits still unconfirmed at your cutoff
Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.
What you can build
Confirm ServiceTitan arrival windows by text
Read tomorrow's appointments with arrivalWindowStart and arrivalWindowEnd, draft one Twilio message each, and propose Appointments_Confirm for every reply that says yes.
Look up each customer by email on the HubSpot contact and use mobilephone when the field service record has no number, so the reminder reaches a phone that receives texts.
At the cutoff, post one Slack message naming each Housecall Pro job with no reply, with the customer and window, so a person can call before the route locks.
When a Jobber client answers that tomorrow does not work, propose a visit change through the schema's mutations with the reply quoted, and leave the original visit untouched until a person approves.
A field service system that exposes tomorrow's appointments by API: ServiceTitan, Housecall Pro, or Jobber
A Twilio phone number or Messaging Service whose inbound message URL points at the reply receiver
A CRM contact with a mobile number for each customer, or a phone number stored on the field service customer record
A send time, a reply cutoff, and the message text you want, set once per business unit
Authentication
ServiceTitan OAuth 2.0 client credentials with an ST-App-Key header, a Housecall Pro API key or a Jobber OAuth 2.0 grant, a Twilio Account SID and auth token, a HubSpot private app token with contact read scope, and a Slack app with chat:write.
Limits
A customer with no mobile number on file is listed for a phone call, not messaged
Twilio reports delivered or undelivered per message; a reply is the only proof the customer read it
ServiceTitan V2 webhooks are gated per app, so new and moved appointments are found by polling the export feeds
Free-text replies are matched to confirm or reschedule; anything else is shown to a person unclassified
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.
What does a person approve before a text goes out?
The evening batch: each recipient, the appointment window, and the message text. Approve sends through Twilio. Reject drops that message and leaves the appointment as it was. Later, each confirmation, hold, or reschedule is its own proposal with the customer's reply shown beside it.
Which record does the job leave behind?
One line per appointment: the system and appointment id, the number messaged, the Twilio MessageSid and delivery status, the reply text and time, what was proposed, and who approved it. The line is kept whether or not anything was approved.
Can it move an appointment on its own?
No. It reads replies and proposes. A confirmation, hold, or reschedule reaches ServiceTitan, Housecall Pro, or Jobber only after a person approves it, and each proposal is sent once for the appointment it names.
Ask about Appointment Reminder
Ask about the capabilities and requirements in this listing.
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