How to vet an automation vendor before you pay

Getting a quote for a new system feels like the easy part. Someone hops on a call, nods along as you describe how your business runs, and a few days later a proposal lands in your inbox with a number attached to it.

The hard part is that the proposal was built off your description, not off what your staff actually do. And those two things are almost never the same.

Why does a quote built off one call go wrong?

A single video call is fast and it scales, so most vendors default to it. The transcript from that call becomes the spec by the next morning.

The problem is whose process gets captured. On a call, you are describing the process you designed, the one that runs cleanly in your head. Your staff run a different one. It picked up exceptions over years: the customer who always pays half cash, the supplier who sends invoices a day late, the step someone added after a mistake three years ago that never made it into any manual.

The system gets built for your clean version. It meets the real one on day one and breaks on the first exception nobody thought to mention. A few months later it quietly stops getting used, and you end up blaming yourself for a tool that was sold to you off a story instead of the actual work.

We have written before about this exact failure pattern in why AI implementations fail. The root cause is almost always the same: nobody watched the real process before building the fix.

What's the one test that catches a bad vendor before you pay?

Ask them to sit with the person doing the job for an afternoon, before they give you a number. Not a call with the owner. Not a survey. An afternoon on-site, watching the actual work happen.

If they agree without pushback, that is a good sign. If they hesitate, try to talk you into a "quicker" call instead, or quote you the same day you spoke, that is your answer before you have paid a single dirham.

This one test does most of the filtering by itself, but a few more honest checks round it out.

Do they time the current process before promising a number?

A vendor who promises "you'll save 10 hours a week" without ever timing how long the current process actually takes is guessing. A real baseline gets measured with a stopwatch, on a normal day and on a busy one, before any KPI gets written down.

If a vendor gives you a guaranteed result before they have watched the work, ask where that number came from. If the honest answer is "your description on the call," you don't have a baseline.

Do they ask about the busy day, or only the normal day?

A process can look fine on a slow Tuesday. The busy day, the one with six customers in the door at once or a supplier delivery landing mid-shift, is where a system actually gets tested. A vendor who only asks about the typical day is scoping for the version of your business that shows up least often.

Do they ask what happens when it goes wrong?

Every process has an exception path: the payment that fails halfway through, the customer who needs something not in the system, the staff member covering for someone on leave. If a vendor never asks what happens when something breaks, they are not planning for it either, and the system will be the first thing standing there with nothing to do when it happens.

Who owns the accounts and data after handoff?

Before you pay anything, know who holds the logins once the project is done. Some vendors keep control of the accounts and quietly turn your business into a subscription. Others hand you the keys outright. Ask this question directly and get the answer in writing before you sign, not after.

What happens if you want to change something small later?

A dropdown menu needs a new option. A field needs renaming. Ask what that costs and how long it takes before you commit to anything bigger. A vendor who cannot answer this clearly, or who treats every small change as a new project, is telling you something about how the relationship will feel a year from now.

Does this filter apply to us too?

Yes, and we would rather you hold us to it than take our word for it. Our own method starts with watching the real work before we quote anything, the same test we are describing here. We call that step a process observation, and it happens with the actual person doing the job, not a description of them.

Every project we scope carries a measurable KPI in the scope agreement, and the baseline for that KPI comes from timing the real process beforehand, never from a call estimate. We wrote about what that looks like in practice in our piece on spreadsheets that quietly became systems, where the fix only made sense once we had actually watched how the file was being used.

If a vendor's pricing feels like a mystery, that is worth asking about too. We keep ours simple: projects start at 7,000 AED, and most land between 10,000 and 35,000 AED depending on scope. The exact number should always trace back to what the process observation actually found, not a guess from a first call.

What should be in writing before you pay anything?

A scope agreement that names exactly what is being built, a payment structure split across milestones rather than paid upfront in full, and a measurable KPI tied to a real baseline. If any of those three are missing, that is a fair reason to pause before paying.

Our custom vs. off-the-shelf breakdown covers more of what should be spelled out before you commit to either path.