Vetting a Software Vendor Before You Sign

Why this matters

When a shop moves its scheduling, invoicing or customer records into a piece of software, it hands that vendor the business's memory. A small shop cannot audit a software company and should not pretend to. What it can do is ask eight plain questions before signing, read the answers for what they dodge, and test three of them during the trial. That takes about two hours and it is the only point at which the shop has leverage: once the data is in and the crew is trained, leaving is expensive and the vendor knows it.

How to use this list

Send the questions in writing, in one email, to the vendor's sales contact, and ask for written answers. Spoken answers on a demo call are worth less, because nobody remembers them a year later and "the rep said" is not a contract term. Ask the questions in the order below. The first two decide whether the rest matter.

Treat three answers as gates: if the vendor fails one, stop, however good the software looks. They are marked below. The rest are weighed against each other and against price.

The eight questions, and why each is there

1. "Can you show me a full export of a test account, every record type including attachments, in a format I can open without your software?" (Gate.)

Ask this first because it is the exit, and every other risk on this list is survivable if you can leave. The answer you want is a self-service export, available to an admin any time, covering customers, jobs, invoices, payments, notes, and the photos and files attached to them, in common formats such as spreadsheet files and ordinary image and document files. Watch for exports that cover customers and invoices but not attachments or notes, exports only on request through support, and exports that come as a single file only their software can read. What breaks if you skip this: you discover the gap the day you try to leave, and the choice becomes paying to stay or rebuilding years of job history by hand.

2. "When we cancel, how long do you keep our data, and will you confirm deletion in writing?"

You want two numbers: a window after cancellation during which you can still export (thirty to ninety days is common), and a point after which your data is deleted, including from backups, which age out on their own schedule. Ask whether deletion can be requested and confirmed in writing. What breaks if you skip this: your customers' records sit on a server you no longer pay for and no longer control, and if that vendor is breached later, they are still your customers.

3. "Can an admin require multifactor authentication for every user, and see who has it switched on?" (Gate.)

Multifactor authentication (MFA) means signing in takes a second proof beyond the password, usually a code from an app or a text. "Available" is not the answer you need. Available means each user can choose to turn it on, and the ones who most need it never will. You want "enforceable": an admin setting that refuses sign-in to anyone without it. A bonus is support for an authenticator app or a hardware key rather than text messages only. What breaks if you skip this: one reused password on one office account opens every customer record you have. See related: Turning On Multifactor Authentication Without Locking Yourself Out.

4. "Does every user get their own login, and is there a log of sign-ins and exports an admin can read?" (Gate.)

Separate logins are what let you remove one person without changing everyone's password. The log is what lets you answer "did a former employee get in after they left." Ask how far back the log goes; under ninety days is thin, because the question usually comes months later. Ask specifically whether exports are logged, since a customer-list export is the most valuable single action anyone can take in the system. What breaks if you skip this: when something goes wrong, there is no record to reason from. See related: The Former Employee Still Had Access.

5. "Where is our data stored, and who at your company can see it?"

You want the country or region where the data is hosted, and a description of when vendor staff can view your account. The good answer is that support staff see your data only when you grant them access for a ticket, and that their access is logged. A list of subprocessors (the other companies the vendor uses to run its service, such as hosting or email providers) is a sign of a vendor that takes this seriously. What breaks if you skip this: you cannot answer a customer, an insurer or a regulator who asks where their information is kept.

6. "Have you had a security incident affecting customers, and how would you tell us if you did?"

An honest vendor of any age has a short answer to the first half; a vendor that says "never" with no qualification is either very new or not answering. The second half matters more: you want a commitment, ideally in the contract, to notify you within a stated number of days of discovering an incident that touches your data. Ask too whether they have an independent security assessment. Larger vendors often have a SOC 2 Type II report, built on the AICPA's Trust Services Criteria: an independent auditor's examination of the vendor's security controls over a period of months; a smaller vendor may offer a written security overview instead. Do not reject a good small vendor for lacking the report, but do ask what they have.

7. "If we take card payments through you, do card numbers ever touch your servers?"

The answer you want is no: the card is entered into a form run by a payment processor, and your vendor holds only a reference token. That keeps most of the card-security burden off the vendor and off you. A vendor that stores card numbers itself carries a much heavier obligation, and so may you. See related: PCI Compliance Explained for a Small Shop.

8. "What does the contract say about who owns our data, price changes, and breach notice?"

You want the contract to say plainly that your data is yours, that the vendor uses it only to provide the service, and how much notice you get before a price increase. Read the actual terms, not the sales summary. If the contract is long or the dollar commitment is large relative to your business, have your attorney read the data, termination and liability sections before you sign. This is not legal advice, and contract language is exactly where a shop should not rely on an article.

Worked example: two vendors for a twelve-person pest control shop

A pest control shop of twelve, running on spreadsheets and a paper route book, shortlisted two field-service platforms. The office manager sent the eight questions to both and got written answers within a week. Here is what came back.

Reading the gates. Vendor A failed gate 1 as asked: no photos and no service notes in the export. For a pest control shop, service notes are where the record of what was applied, where, and at what rate lives, and that record has to outlive any software choice. Vendor A also half-failed gate 4: a 30-day sign-in log with exports unlogged cannot answer the question gate 4 exists for. On the gates alone, Vendor A was out, though it was noticeably cheaper.

The reasoning the office manager wrote down. She did not stop at the table. Vendor A's incident answer was actually a point in its favor: it named a real event and said how customers had been told. Vendor B's clean record over a few years told her less than A's honest one. What tipped it was not the incident history but the export and the log, the two things that decide whether the shop can leave cleanly and investigate when something goes wrong.

What would have changed the answer. If Vendor A had offered a full export through support on request within a stated number of days, gate 1 would pass with a caveat, and the price difference might have carried it. If the shop had kept its application records in a separate system of record required by its state's pesticide regulator, the missing notes in A's export would matter less. And if both vendors had failed gate 1, the right move was to ask a third, not to pick the less bad of two.

The failure mode the shop avoided. The shop's previous attempt, two years earlier, had picked a platform on a demo call alone. When they cancelled, its export turned out to be invoices only, and the office spent most of a month re-keying customer service histories from screenshots. That cost was the reason the office manager insisted on written answers this time.

Testing the answers during the trial

Written answers tell you what the vendor believes. Three of them can be checked during a free trial, and they are the three gates.

Run the export. Put five fake customers into the trial, add a job, a note and a photo to each, then run the export and open the files on a computer that does not have the software. Count what came out against what went in: five customers, five jobs, five notes, five photos. If any count is short, the written answer was wrong.

Enforce MFA and try to break it. Turn on the admin setting, then try to sign in as a second trial user who has not set it up. The sign-in should be refused or forced into setup. If it lets you in, "enforceable" meant something else.

Read your own log. Sign in from a second browser or a phone, run an export, then open the admin log. Both events should be there with a time and a device. If the export is missing, gate 4 has not passed whatever the email said.

Vendor B passed all three in the trial. The shop signed, and the office manager saved the vendor's written answers in the same folder as the contract, because the next time anyone asks "what did they promise us," that email is the answer.

References

• See related: Turning On Multifactor Authentication Without Locking Yourself Out
• See related: PCI Compliance Explained for a Small Shop
• See related: Customer Data Retention: What to Keep and What to Destroy
• AICPA SOC 2 reporting framework (Trust Services Criteria), for what a SOC 2 Type II report examines