To connect field service software to your CRM, first decide which events the CRM needs to hear about. For most service businesses that's four: a new customer, a new service request, a completed job and a paid invoice. Then pick how those events get there: a manual export, a built-in connector, a developer polling an API, or webhooks that send each event as it happens. Past a handful of technicians, webhooks are usually the one that keeps the CRM current without someone babysitting it.
Here's how to choose, and what to sort out before the first record moves.
Why the CRM falls behind
You bought the CRM to follow up with customers: the maintenance reminder, the "how did we do" email, the offer on the second system. It only works if the CRM knows what happened in the field.
In most shops, it doesn't. The install finishes Tuesday. Someone's supposed to update the CRM, and it's Friday before they get to it. By then the automated "your install is coming up" email has already gone out to a customer whose install is done. That's worse than sending nothing.
Step 1: Decide what the CRM actually needs
Don't try to copy everything. Start with the four events that drive follow-up:
- A new customer. Add them to the CRM so they get the right welcome and reminders.
- A new service request. Treat it as a lead or an open opportunity.
- A completed job. Move the deal forward, log the visit and start the follow-up.
- A paid invoice. Record the revenue and stop any payment-reminder sequence.
That covers most of what a service business uses a CRM for. You can add more later.
Step 2: Decide which system owns what
Before anything moves, agree on one rule: which system is the record for which data?
A common split: your field service software owns jobs, schedules, technicians and invoices. Your CRM owns marketing preferences and sales notes. Customer contact details are the tricky one. Pick one place where people edit them, and let the other receive copies. If both systems accept edits and both send changes to the other, you'll spend Monday mornings working out which phone number is right.
Step 3: Pick how the data gets there
There are four ways. None is always right.
Manual export and import
Export a CSV of the week's jobs and customers and import it into the CRM. It suits a small team, a lightly used CRM or a one-time catch-up. The catch: it's only as current as the last export, and it depends on a person remembering.
A built-in connector
Some software ships a direct connector to specific CRMs. When one exists for exactly your CRM and does what you need, it's the easy route. The catch: connectors do what they were built to do and no more, and if your CRM isn't on the list, the option doesn't exist.
A developer polling the API
A developer writes a script that asks the field service software's API "anything new?" every few minutes and copies changes across. It works for custom setups with a developer on hand. The catch: most of those checks find nothing, and each one uses up your API allowance. Poll less often and the CRM falls behind again.
Webhooks
The field service software sends a message to an address you choose each time something happens: a job completed, an invoice paid. Your CRM, or an automation tool sitting in between, acts on it. Nobody has to remember anything. The catch: something has to receive the webhook, either a small service your developer runs or an automation tool that listens for webhooks. We walk through the automation-tool route in sending field service jobs to Zapier with webhooks.
Rule of thumb: under five technicians and a lightly used CRM, a weekly export is fine. Past that, the manual step is where things break, and webhooks are worth the setup.
Step 4: Watch for three problems
These cause most of the "the integration is broken" calls.
Matching customers. When a completed job arrives, the CRM has to find the right customer. Name matching fails ("Bob's HVAC" and "Bobs H.V.A.C." are the same shop). Store the field service software's customer id in a field on the CRM record when the customer is first created, and match on that.
Duplicates. Webhook senders retry when your side doesn't answer in time, so the same event can arrive twice. Good senders put a unique id on each event. Record the ids you've processed and skip any you've seen, or you'll get two "job completed" notes and two follow-up emails.
Changes after the fact. Jobs get deleted, restored and edited. Decide what the CRM should do when a completed job is later deleted: remove the note, or flag it for someone to check. Flagging is usually the safer answer.
Questions to answer before you build it
Who owns it when it breaks? Every connection fails eventually: an expired API key, a CRM field someone renamed, an endpoint that moved. Name one person who checks it, and make sure they know where the delivery log is.
What's the backfill plan? Webhooks cover what happens from now on. Customers and jobs from before the connection went live need a one-time import, usually a CSV into the CRM. Do that first, so the ids match from day one.
What should the CRM not do? Resist wiring the CRM to change jobs or schedules in your field service software. Keep data flowing one way to start. Two-way syncs are where most integration headaches come from.
A worked example
A 15-technician HVAC shop wants its CRM to handle maintenance follow-up. Here's the setup:
- New customer → create the contact in the CRM, with the field service customer id stored on it.
- New service request → open an opportunity on that contact.
- Job completed → move the opportunity to completed, log the visit date and job type, and start the maintenance-plan email sequence for new installs.
- Invoice paid → mark the opportunity won and stop any payment reminders.
Four events, four actions. The office stops updating the CRM by hand, and follow-up goes out on the right day. For more ideas, see six things teams build on a job completed webhook.
How FSM Navigator connects to your CRM
FSM Navigator runs the customer lifecycle in one app: customers book online, you send a quote they sign on their phone, the right technician gets the job, and the invoice goes out before the truck leaves the driveway. Service agreements then bring the customer back. What it doesn't have is a built-in connector for any particular CRM. It uses webhooks, which work with any CRM or automation tool that can receive them.
On Enterprise, FSM Navigator sends a signed webhook when:
- a job is created, updated, changes status, is completed, deleted or restored;
- an invoice is fully paid, including when a disputed payment comes back to you;
- a new customer is added;
- a service request comes in from your booking page or the customer portal.
The Owner and Managers add endpoints in the dashboard and tick the events each one should get. Every delivery is logged for 30 days, failed deliveries are retried, and each event has a unique id so your CRM side can skip duplicates. The webhooks developer docs cover the payload, signatures and retries.
For detail your CRM wants beyond the event, the Enterprise REST API lets your developer fetch customers, jobs and more. Webhooks and the API are both on the Enterprise plan; see pricing for plans and API allowances.