All Posts
· Laine · 7 min read

Salesforce for Field Service Companies: Equipment First

Salesforce for field service companies should start with the equipment you service, not a dispatch board. What to build first, and when to buy more.

SalesforceField ServicePreventive MaintenanceCustom ObjectsAISentinelCRM
Salesforce for Field Service Companies: Equipment First, Sentinel blog cover

Salesforce for field service companies usually starts with the wrong question. Owners ask “how do we dispatch technicians from Salesforce?” when the thing their CRM actually can’t answer is simpler: what equipment do we service, where is it, and when is it due? My position: if you sell and service equipment on contract, model the installed base first. Dispatch software is worth buying when dispatch is your bottleneck, and for most mid-sized service businesses it isn’t yet.

The Customer Isn’t the Unit of Work. The Equipment Is.

Think about how a commercial service business actually earns money. A building owner signs a maintenance agreement covering three rooftop units, a boiler, and a backflow preventer. Your technicians visit each piece of equipment on a schedule, find problems, fix some of them on the spot, and quote the rest.

Standard Salesforce sees one Account and maybe one Opportunity for the agreement. Everything that matters operationally lives below that: five machines, each with an install date, a model, a warranty, a service history, and a next visit due.

When that layer is missing, it gets rebuilt somewhere else. A spreadsheet per customer. A paper binder in the truck. A separate service app that knows the equipment but not the sales history. The office can tell you what the contract is worth. Nobody can tell you which units are fourteen years old and one bad summer from replacement.

That’s the gap. The dispatch board is a symptom.

Three Questions Your CRM Can’t Answer Today

If your service data is scattered, run this test. Try to answer each of these from Salesforce alone, in under a minute.

Which maintenance visits are due in the next 30 days, by technician territory? If the answer lives in someone’s calendar or a recurring reminder, your schedule depends on one person remembering.

Which service agreements renew next quarter, and what did we spend servicing each one? Without visit history tied to the agreement, renewal pricing is a guess. You can’t tell a profitable contract from one you’ve been subsidizing.

Which customers have aging equipment we should be quoting for replacement? This is where the revenue is. Replacement and repair work found during maintenance is the natural sales pipeline of a service company, and most CRMs never see it until a technician remembers to call the office.

If you can’t answer all three, adding a scheduling tool on top won’t fix it. You’d be scheduling visits against data you still don’t have.

What to Build: Four Pieces, Not a Platform

You don’t need an exotic design. You need four things sitting next to your existing Accounts and Opportunities.

1. Equipment on site

Salesforce ships a standard Asset object, and for many shops it’s the right starting point: link each Asset to the customer Account, then add the fields you actually use, such as make, model, serial number, install date, refrigerant or fuel type, and a location description (“roof, north side”). If your customers have multiple buildings, add a simple Site object so equipment hangs off the right address instead of the billing address.

2. The agreement, with coverage

A Service Agreement custom object holds the contract: start date, renewal date, visit frequency, and price. A junction record ties it to the specific equipment it covers. That junction is the piece people skip, and it’s the one that lets you answer “is this unit under contract?” without opening a PDF.

3. Visits that create themselves

A Visit object records each trip: date, technician, equipment serviced, findings, and time on site. The automation that matters is generation. When an agreement is signed or renewed, the next year of planned visits gets created from its frequency. A quarterly agreement on five units produces the right visits without anyone typing them in.

4. Findings that become pipeline

Give each Visit a findings field with a short picklist, such as “recommend repair” or “recommend replacement”, plus a notes field. When a technician flags a recommendation, Salesforce creates an Opportunity on the Account, linked to the equipment, assigned to the right salesperson. The replacement quote stops depending on a phone call.

Roll-up fields finish the picture: total visit hours per agreement, open recommendations per account, last visit date per unit. If those roll-ups cross a lookup rather than a master-detail relationship, the approach in roll-ups Salesforce won’t give you covers how to get them anyway.

Where Renewals and Assignment Fit In

Two automations you may already have elsewhere become far more useful once this model exists.

Renewal alerts. With visit cost rolled up to each agreement, a renewal alert can carry the number that matters: what servicing this customer actually cost last year. We covered the alert pattern in renewal alerts your CRM should have had all along; in a service business, you just point it at Service Agreements instead of Opportunities.

Assignment. Planned visits need an owner. For a small team, a territory-plus-rotation rule is plenty, the same logic as round-robin lead assignment applied to visits by service area. That isn’t route optimization, and it doesn’t pretend to be.

The replacement Opportunities those findings create also connect to quoting. If your quotes involve configured equipment, the patterns in Salesforce quoting for manufacturers apply almost unchanged.

When to Buy Salesforce Field Service Instead

Salesforce sells a dedicated product for this world, and it’s good at what it’s built for: scheduling optimization across many technicians, a dispatcher console, a mobile app for crews in the field, and work orders with parts tracking. It’s licensed per user on an annual contract, and per Salesforce’s Field Service pricing page it requires at least one Service Cloud user license, and technicians need at least one Dispatcher license in the org before they can use the scheduling tool.

Here’s the honest line I’d draw:

  • Buy it when the hard part of your day is routing: many technicians, tight appointment windows, emergency calls reshuffling the board, crews who need offline mobile access.
  • Build first when the hard part is knowing what’s due, what’s covered, and what to sell. That’s a data model problem, and a dispatch tool assumes you’ve already solved it.

These aren’t mutually exclusive. If you do adopt Field Service later, a clean installed base and agreement history make that implementation easier, not harder. It’s the same build-versus-buy reasoning we laid out in AppExchange vs. custom build: buy the platform when you need the platform, build the piece that’s specific to how you run.

How This Gets Built Without a Six-Month Project

None of the four pieces is a big project on its own. Each is a few objects, some fields, a page layout, and one or two automations, the kind of work in our list of small Salesforce projects that rarely justifies a consultant engagement but never makes it to the top of an admin’s queue.

That’s where an AI developer fits. With Sentinel, you describe the model in plain language (“equipment belongs to a site, sites belong to accounts, agreements cover equipment through a junction, visits generate quarterly from the agreement”) and your AI builds it in your org. Deploys go to a sandbox first with tests required, every change is logged, and a snapshot is taken before anything is deployed, so if the Visit generator does something you didn’t expect, you can see exactly what changed and roll it back. The deployment safety post has the detail for anyone who wants it. Pricing is flat per Sentinel and is covered on a short demo call.

Start With One Customer’s Equipment

Don’t load the whole installed base on day one. Pick your largest maintenance customer, create their sites and equipment, attach their agreement, and let the system generate the next year of visits. Then try the three questions again.

If the answers come back in under a minute, roll it out customer by customer. If they don’t, you’ve learned which piece of the model is missing for the price of one account, not one implementation.

Service companies that grow cleanly aren’t the ones with the fanciest dispatch board. They’re the ones whose CRM knows every machine they’re responsible for, and what it’s going to need next.

Want to see this model built against your own customer list? Book a Demo Call and bring your biggest maintenance contract.

See Sentinel build in your own CRM on a 30 minute call.

Book a Demo Call