Specialism
ServiceTitan integration consultant for the systems around your dispatch board
The platform already runs the jobs. What it cannot do on its own is make your CRM, your ledger, and whatever answers the phone at nine at night agree with it about the same customer, the same price and the same appointment — and every one of those disagreements eventually lands on a dispatcher's screen in the middle of a working day.
The work
What does connecting the platform to the rest of your stack involve?
Four pieces, in this order: authorised access scoped to what the build actually needs, an agreed owner for every field that exists in two places, writes that respect the constraints the office already works to, and a queue a person reads when one of them is refused. The plumbing is rarely the hard part. The agreement between the systems is.
Access and scope. Integration work here starts with an application authorised against your tenant — your own instance of the platform and the data inside it — rather than with anyone's personal login. Access is granted per area of the product and issued as short-lived tokens, which has two consequences worth knowing before a scope is agreed. A build should request only the areas it genuinely touches, because an integration holding read and write access across the whole account is a standing risk nobody reviews afterwards. And credentials expire, so a connection nobody exercises through a slow month can lapse quietly and be discovered on the morning it mattered. The areas, the limits and the request ceilings are published in ServiceTitan's developer documentation (opens in new window), and we build to what is documented rather than to what a forum post claims still works.
Events, not polling. A webhook is a message the platform sends the moment something changes — a job completed, an estimate sold, a membership renewed — so the systems around it react in seconds without anyone asking "anything new?" every five minutes. Where an event exists for the thing you care about, it is almost always the right trigger: it is cheaper against the request limits, it is faster, and it carries the record identifier you need to fetch the detail. Where one does not exist, a scheduled read has to be written so that it can run twice without doing anything twice, because it eventually will.
Pricebook and dispatch are constraints, not tables. The pricebook is the priced catalogue of services, materials and equipment that technicians build estimates from, and it should have exactly one owner. Another system writing into it produces near-duplicate items, estimates priced from a stale copy, and reporting that stops reconciling. The dispatch board is the live grid of technicians, shifts, arrival windows and capacity that the office works from all day. Automation can create and update the work on it; automation should not be inventing slots that no one can cover, or quietly reassigning a technician who is already halfway across a service area. Booking writes go in against real availability, and the judgement stays with the dispatcher.
Boundaries with accounting and the CRM. The expensive version of this project is the one that builds a second path to the ledger beside the export the platform already runs. Invoices and payments keep one owner and one route; custom work handles what that route does not carry — the reconciliation nobody has time for, the records that live in a spreadsheet between the two systems, the job-costing detail that arrives after the fact. The same discipline applies on the sales side: if the CRM and the platform both believe they own a customer's contact details, the one the technician sees is decided by whichever sync ran last, which is not a decision anybody made.
| Record | Where it should be owned | Direction we build | Failure mode if left undecided |
|---|---|---|---|
| Customer and service location | The platform | In at intake, out to the CRM afterwards | Two records for one address, and a technician sent to the old one |
| Booked appointment | The dispatch board's capacity and arrival windows | Written in against real availability, never invented outside | Jobs on the board with no capacity behind them, re-done by hand |
| Pricebook item | The pricebook | Read-only everywhere else | Duplicate items, stale prices quoted, history that stops reconciling |
| Estimate and its options | The platform, where the technician builds it | Out to reporting and follow-up | A number quoted to the homeowner that differs from the one on the tablet |
| Invoice and payment | The existing accounting export | One path only, never a second sync | The same invoice raised twice in the ledger and unpicked at month end |
| Membership and renewal date | The platform | Out to whatever runs the follow-up | Renewal campaigns firing on plans already renewed, or lapsed ones missed |
| Inbound call or web enquiry | Whatever captured it first | In, as a booking or a lead, with its source attached | Enquiries ageing in a form inbox while the board looks quiet |
| Technician availability and shifts | The dispatch board | Read-only to every outside tool | Booking software promising a slot nobody can cover |
Writes here reach a person's day, not just a database. A CRM mistake is embarrassing; a bad write here puts a van on the wrong street. So integration work is staged against a test environment first, bulk changes run inside a window rather than at eight in the morning, and anything that contacts the homeowner directly — the reminder, the on-my-way text, the review request — is built to the consent and opt-out rules summarised in the FCC's guidance on telemarketing and robocalls (opens in new window), with your own counsel signing off the channels that need it.
Where it fits
Should an automation write into the platform, or stop one step short?
Write in wherever the decision has already been made somewhere else and the platform is simply the last place it needs to land: a homeowner who picked a slot, a membership that renewed, a lead that arrived with everything a dispatcher needs. Stop short wherever judgement is still involved — pricing an unusual job, promising a same-day arrival on a full board, deciding which technician takes a difficult call. Most contractors end up running both patterns, and the value is in choosing which is which deliberately rather than letting an app's defaults decide.
This page is about the integration surface — scopes, events, pricebook and dispatch constraints, and the sync boundaries either side. If the question is really about outcomes rather than plumbing, the better reads are elsewhere. AI automation for home service companies covers the missed call, the booking gap and the follow-up that never goes out, whatever software sits underneath. AI automation for pest control companies does the same for recurring plans, where the renewal that quietly lapses costs more than the call that rings out. If your office is a few crews rather than a dispatch team, the platform underneath is probably Jobber, and the constraints are different enough to need their own page — a Jobber integration consultant is working with clients, quotes, jobs and visits, and with an accounting sync that already owns the ledger. When the bottleneck is the booking flow itself rather than the connection, AI appointment scheduling describes how intake from web, phone and SMS reaches a real calendar without double-booking anyone. Where the ledger is the awkward end of the chain, our QuickBooks integration consultant page covers field ownership and idempotent writes on that side of the boundary. And if you are not yet sure which process deserves the first build, a workflow automation audit hands back a ranked backlog before anybody writes code.
A new connection, or repairing one that drifted
Both are common, and the second is more common than people admit. A new connection is mostly mapping: agreeing the entities, the matching keys and the direction of every shared field, then building against a test environment. A repair starts with a reconciliation — what is in the platform that should not be, what never arrived, and which of the three tools currently writing to the same customer is winning. Where a published app already covers your case properly, installing it beats building anything, and we will say so.
What we do not claim
We hold no badge from the vendor and will not imply one. Access to your tenant is granted by your administrator, scoped to the areas a build touches, and revocable the day you want it gone. What we bring is integration judgement: which processes are worth connecting, which system should own each field, and what happens on the day a sync fails silently in the middle of your busiest week. If a certified partner is genuinely what the job needs, that is the recommendation you will get.
Questions
Practical questions from contractors and office managers
Are you a certified ServiceTitan partner?
No, and we will not imply a badge we do not hold. We are an independent consultancy that builds against the published API, inside your own tenant, with access your administrator grants and can revoke. If a certified partner is genuinely part of what you are buying, that is the honest recommendation and we would rather say so than be vague about it.
Can automation create jobs and move them around on the dispatch board?
Creating and updating jobs through the API is ordinary work. Deciding who drives to them is not something we hand to software. We write bookings and job details in against real availability, and leave assignment, capacity judgement and the resequencing of a bad morning with the dispatcher who can see the whole board.
We already export invoices to our accounting system. Does this replace that?
No, and building a second path into the ledger is the most expensive mistake we see on these projects. The platform's own accounting export keeps ownership of invoices and payments. Custom work belongs around it: the records it does not carry, the systems it never touches, and the exceptions somebody currently fixes by hand each month.
What happens when a write is rejected or the rate limit is hit?
The item lands in a queue with its reason attached, nothing half-written is left behind, and the run carries on with the records after it. Throttling and transient failures retry on a backoff. Anything rejected for a real reason waits for a person and is visible the next morning rather than discovered at month end.
What do you need from us before any of this can start?
API access, which your tenant grants rather than we do: somebody with administrator rights authorises the application and chooses which areas it may read and write. We tell you which scopes a build actually needs and why, and we start narrow and widen later rather than asking for keys to everything on day one.
Free consultation
Tell us what is costing you the most time
Describe the process. You get a straight read on whether it is worth automating, roughly what it would take, and what we would tackle first — on a call that costs nothing.
- Under an hour, free, and no obligation
- Fixed price per stage, agreed before any work starts
- You own everything we build, documented and in your accounts
- If you do not need us, we will say so on that call
The form is the fastest way to reach us — we reply from a real person, usually within one business day.
Also see: AI voice agent development for the after-hours calls that have to become bookings before any of this plumbing matters.