Vendor Lock-In With Field Service Software, Explained

You signed up three years ago because the scheduling was better than a whiteboard. Now your customer list, your job history, your texting number, your card processing and the booking link on your website all run through one company. You're not thrilled with the price increases. But you also don't know what leaving would actually cost you, and nobody at the vendor is in a hurry to explain it.

Vendor lock-in with field service software isn't one thing you can point at. It's five separate things, each with its own key, and most owners only find out which ones they hold on the day they try to leave.

By the end of this you'll know which locks you're sitting behind right now, and which ones are worth accepting.

Vendor lock-in with field service software is five locks, not one

Owners talk about being stuck with their software like it's one big door. It's closer to five doors, and on most setups you already hold the key to a few of them. You just don't know which ones.

Picture a plumbing shop that decides to move off its platform. The customer list exports cleanly. The crew picks up the new app inside a week. Then someone realizes the texting number customers have been replying to for years was issued inside the old platform. It's registered to the vendor, not the shop. Cancel the account and every "can you come Tuesday" text goes into a dead box. So the shop stays, pays the higher rate, and tells itself it wasn't that bad.

Four doors open, one locked, and the locked one was enough.

That's why switching costs are hard to size up from the outside. They're not one bill. They sit in five separate places: your customer and job data, your phone number and texting setup, your payment processing connection, your listings in the app stores, and the code and APIs holding it all together. Each one is owned by somebody — you or the vendor — and the paperwork that decides which is usually settled on the day you sign up.

Vendor lock-in with field service software is really a question of whose name is on each of those five accounts.

The first lock is your CRM data and job history

Every owner asks about this one first, and they're right to. Ten years of customers, addresses, equipment models, service history, the photo of the crawlspace you took before you touched anything — that's the record of the business. Lose it and you're quoting blind.

Most vendors will tell you that you own your data. Fine. The question is what shape it comes out in.

Getting your data out usually means one of three things:

• A CSV export of customer names, addresses and phone numbers. Nearly every system offers this. It's the easy part.
• Job history tied to those customers — past work, notes, equipment serial numbers. Sometimes exportable, often flattened into a mess you'd have to rebuild by hand.
• Photos and attached files. This is where it breaks. Photos frequently live in the vendor's storage and come out, if at all, as a zip with filenames that no longer connect to the job they belong to.

That third bullet is the one that catches people. You can export your CRM records in an afternoon and still spend a month re-attaching pictures to jobs.

Real data portability means the export preserves relationships, not just rows. A customer linked to their jobs, each job linked to its notes and photos. Ask any vendor for a sample export file before you sign, not a description of one. Open it yourself.

And know that data migration is work no matter who's doing it. A clean export still has to be mapped into the new system's fields. Budget time for it, and do it before your busy season, not during.

The second lock is your phone number and texting integrations

Your phone number is the business. Trucks, yard signs, the Google listing, ten years of repeat customers with it saved in their contacts. So when a vendor sets up missed-call text back, they often do it by putting a number they control in front of yours, or by registering a new number and forwarding your old one into it.

That works fine right up until you leave.

Ask who the carrier account belongs to. In most setups the texting runs on a provider like Twilio, and the question is whose name is on that account and whose card pays it. If it's the vendor's, your number is sitting inside someone else's billing relationship, and getting it out means a port request they have to cooperate with. Porting a number between carriers takes days, not minutes. A crew that books work by phone cannot go dark for days.

Then there's the message history. Every text thread with a customer, every photo a homeowner sent of a leaking water heater, lives in whatever system handled the messaging. Some platforms let you export threads. Many only show them in the app, and the integrations that pull them out are read-only or don't exist. Ask whether there are APIs that let you pull your own message history, and ask to see what comes back.

Two things to check this week. Log into your carrier account directly, not through the field service app, and confirm you can. Then look at who gets the bill for the texting. If you can't answer either one, you've found a lock.

The third lock is payment processing, where switching costs hide

Most field service platforms either own the payment processing or have a short list of processors they'll connect to. You send an invoice, the customer taps a link, the money lands in your account, and the invoice marks itself paid. That loop is the part owners miss when they plan a move.

Exporting your invoice history is one job. Rewiring how money moves is a different one. You need a new merchant account or a new connection to your existing one, new payment links, and a way to handle invoices that are already out in customers' inboxes with a link pointing at the old system. Card numbers saved on file for a maintenance plan usually don't come with you. Some processors will migrate stored cards to another processor; many won't, and the customer has to enter the card again.

Three things worth knowing before you're in a hurry:

• Whose merchant account is it. If the application has the platform's name on it and not your company's, that's their account with your money passing through it.
• What the contract terms say about processing fees, minimum terms and early cancellation. Payment agreements often run separate from the software agreement, with their own end date.
• Which integrations your bookkeeper depends on. If deposits flow into QuickBooks or whatever ERP your books run on through the platform, that sync breaks the day you leave.

Call your processor and ask who the merchant of record is. The answer takes a minute and tells you how hard this lock is.

The fourth lock is your app store listings

Most owners never think about this one until the day they try to leave.

If your crew uses a branded mobile app, someone had to publish it. Apple and Google both require a developer account, and whoever owns that account owns the listing. With most SaaS field service products, the app in the store is the vendor's app, running their proprietary code, with your crew logging in as users on their system. Nothing about that is shady. It's just how a shared platform works.

The problem shows up at the handover. You can't move a listing you don't control, and you can't republish under a new account without your techs deleting the old app and installing a new one. If a tech's phone is their whole workday — job list, notes, photos, signatures — that's a bad morning across the crew.

If the app carries your company name and logo, it's worth knowing whose developer account it was published from. Ask directly. If the answer is the vendor's, that's fine, but now you know a switch means a reinstall and new logins for everyone.

Where it gets simpler: an app published under your own company's developer account stays yours. The code may change hands. The listing, the reviews and the install base don't move.

The fifth lock is the APIs and code underneath

Software is built out of parts that talk to each other. Your scheduling screen talks to your database. Your invoice page talks to the payment processor. Those connections run on APIs, and each one needs a key — a long string of characters that proves your system is allowed to make the request.

Whoever holds those keys controls the connections. Whoever owns the code controls everything else.

If the code is proprietary to the shop that built it, you're not buying software. You're renting access to theirs. A new developer can't read it, can't fix it, can't add the one field your office keeps asking for. Your only option is to pay the original builder or start over.

If the code is yours, it sits in a repository you can hand to anyone. The cloud account it runs on is in your company's name, billed to your card, and that holds in a multi-cloud setup where different pieces sit with different providers. A new developer gets added as a user and starts work. No rebuild, no export, no six weeks of downtime while someone reverse-engineers how your dispatch board works.

Ask the question plainly before you sign: if we hired a different developer next year, what exactly would we hand them? A good answer is a list. A vague answer is the lock.

Vendor lock-in isn't only the vendor's fault

Some of the stickiness you feel is something you asked for.

A system built around your shop knows your service list, your dispatch rules, your price book, your three techs and which of them handles boiler work. It knows that your office manager wants the morning report at 6:40, and that a quote over a certain size gets a call instead of a text. That fit is the reason it saves time. It's also the reason it doesn't lift cleanly out and drop into something else.

Generic field service software is easier to leave because it never bent to you in the first place. Everyone's job form has the same fields. Your process got reshaped to match the software, so the next piece of software can reshape it again at roughly the same cost. That's a real advantage and it's worth naming.

So part of what gets called vendor lock-in is just the cost of a custom system. The work that made it fit is work someone would have to do again. No contract clause removes that.

What a vendor controls is whether the fit comes with extra locks stacked on top. Whether your customer list is exportable. Whether the phone number is in your name. Whether the payment account belongs to you. Whether the code is readable by someone else. Those are choices, and they're separate from how well the system matches your crew.

Judge the two things apart. Ask how much of the switching cost is your own process being baked in, and how much is the vendor holding the keys. The first is a fair trade. The second isn't.

Sometimes a rented SaaS platform is the smarter bet

If you've been in business eight months and you're still arguing with yourself about how jobs should get scheduled, don't buy a custom system. Rent one.

A monthly SaaS plan is cheap to leave. Jobber, Housecall Pro and ServiceTitan all sell that way, and the ability to cancel at the end of a billing cycle has real value when your process is still moving. You get someone else's opinion about how a trade shop should run, which is useful when you don't have a settled opinion of your own yet. You learn what you actually need by using something and noticing what annoys you.

The switching costs are lower in both directions. Low to get in, low to get out. That's the whole point of the model, and it's an honest one.

The trade is that you shape the business around the software. Your quote template is their quote template. Your job flow is whatever the vendor decided a job flow should be. For a three-person crew doing fairly standard work, that's often fine, and sometimes better than what an owner would have designed on their own.

Read the contract terms anyway. Month-to-month on the marketing page sometimes becomes an annual commitment on the order form, and export tools vary a lot between platforms. Ask what the data export actually produces before you need it.

Custom makes sense later, when you know what your office does every day and the software keeps telling you no. Before that, you're paying to build the wrong thing carefully.

How First-Rate Tech handles all five locks the same way

The structure is the same for every one of them. The account gets opened in your company's name, on your company's card, and we hold access to it. Not ownership.

That means the database your customer and job records live in is yours. The phone number and texting setup is registered to your business. The payment processor connects to your merchant account, under your EIN. If you publish a crew app, the developer account is your company's. The code sits in a repository your business owns, and we're a collaborator on it.

Day to day, nothing about that feels different. You call us when something breaks, we go in and fix it, same as any provider. The difference only shows up the day you want to leave. There's no export request, because there's nothing to export. We remove our access and you change the password. The accounts keep running because they were never ours to shut off.

Data portability stops being a feature you have to ask for when the database is already in your name. You can point a bookkeeper at it, hand it to a different developer, or pull a full copy on a Tuesday afternoon for no reason at all.

The same goes for the connections between pieces. The integrations between your scheduling, your texting and your invoicing run on APIs that live in your accounts, with your keys. A new developer reads the code, reads the documentation for the services it talks to, and gets oriented. That's normal work, not archaeology.

We'll say the honest part out loud: a system built around your crew and your process is still harder to hand off than a template. Someone has to learn how your jobs actually flow. What we can remove is the part where a vendor decides whether you get to keep your own records.

Worth a conversation about your setup: New Project Consultation

Questions to ask about contract terms before you sign

Sales calls are the one moment you have leverage. Ask these out loud, write down the answers, and ask for them in writing.

1. "Can I export my full job history, including notes and photos, and in what format?" A customer list is not your records. You want jobs, quotes, invoices, payment history and the notes your techs typed on site. Ask what the export file actually looks like. Ask whether you can run it yourself or have to request it.

1. "Who owns the phone number my customers call?" If the answer is the vendor, ask what the release process is and what it costs. If the answer is you, ask who the carrier account is under and whether you can log in today.

1. "Who owns the payment processing account?" You want the merchant account in your business name, with your bank details, where you can pull statements and dispute records without asking anyone.

1. "If there's a mobile app, whose developer account is it published under?" Listings move between accounts, but only with the current owner's cooperation. Know who that is before you have customers using it.

1. "Who holds the code, and what happens to it if we part ways?" Ask where the repository lives and whether a new developer could be given access without the vendor's permission.

1. "What does data migration look like on the way out?" Not just on the way in. Ask whether they've handed a client off before and what that took.

Two phrases to listen for in the contract terms themselves: notice period and termination. Thirty days' notice means something different when the export takes three weeks.

Any vendor serious about data portability will answer these fast. Hesitation is the answer. So is a long explanation about how their APIs are proprietary.

The real test: could you fire your provider on a Friday and still run Monday

Run the thought experiment for real. It's Friday afternoon. You send the email. Monday morning the phone rings at 7:15 and a customer wants a tech out.

Walk it through lock by lock. Can the office pull up that customer's history? Does the missed-call text still go out, or did it die with the account? When the tech finishes the job, can he take a card? If a customer searches your name in the app store, is your app still there?

If the honest answer to any of those is "I'd have to ask," that's where your vendor lock-in lives. Not in the contract. In the one account nobody can log into without making a phone call.

Some switching costs are fair. A system shaped around your crews and your process takes work to rebuild, and that work bought you something. The costs worth refusing are the ones that exist only to make leaving hard — a number you can't port, data in a format nobody else reads, a login held in someone else's name.

Fix those while you're happy with your provider. Nobody fixes them in the middle of a breakup.

If you want to walk through where your own five locks sit, book a New Project Consultation.