What Questions Should You Ask Before Commissioning an Automation?

Before you commission an automation, ask six questions: What counts as delivered? How will the savings be measured? Who notices errors? Who owns data and access? How long are you bound? What does the first year cost in total? The answers show you before you sign what you would otherwise only learn in live operation.

Why do the questions before you sign decide more than the technology after?

Because a job can only be delivered as precisely as it was described. Whatever you don't pin down before you sign, daily operation pins down later, and rarely in your favor.

The mechanics are simple. You commission a result, the provider delivers a service. Between the two lies a gap as long as nobody has written down how you will recognize the result.

That is not a technology problem. That is a description problem. And the description is in your hands, not the provider's.

You know the pattern from every other job you hand out. Order "a new bathroom" from a tradesperson and you get their picture of a bathroom. Order dimensions, materials and a completion date and you get yours. The tradesperson is the same in both cases. The difference lies in what you specified beforehand.

With an automation this weighs heavier, because you cannot touch the result. A process that runs on its own is invisible as long as it runs. You only see it when something fails to happen. That is why you need criteria beforehand that you can measure it against.

You may be thinking: the provider handles that, they're the expert. For the technology, that's true. For your result, you are the expert, because only you know what the process has to deliver in your business.

I'm assuming you have already chosen your process. If not, the criteria for choosing one are: recurring, clearly bounded, one trigger, one result. The six questions here pick up after that choice, and they apply to every provider, including me.

What exactly counts as delivered?

An automation counts as delivered only once it demonstrably runs on its own, not once it has been demonstrated to you. Get the acceptance criteria in writing before you sign.

A demonstration shows you that something can run. Acceptance shows you that it does run. Those are two different states, and you're paying for the second.

The difference lies in the conditions. In the demonstration, the provider triggers the process themselves, with test data, at a time of their choosing. In your business, a real customer triggers it, with incomplete details, on a Friday evening. Only there do you see what you actually got.

At imprUvement I've put acceptance into four checkpoints, exactly as they appear on our pricing page: The trigger fires on its own. The result lands in the right system. Errors report themselves. The whole thing runs stably for two weeks.

Each of these points closes a gap you would otherwise only see later. "On its own" means nobody has to kick off the process. "In the right system" means the appointment sits in your calendar, not in a list nobody opens. "Two weeks" means the process has also seen the cases that didn't come up on day one.

You don't have to adopt these four points. But ask your provider for theirs. If they can't name any, their gut feeling will ultimately decide when your job is finished.

The second half of the question is: what happens if the criteria aren't met? Rework, refund, or neither. With me it's one of the first two: I fix it free of charge, or you get the amount for the pilot back. How your provider handles it belongs before the signature.

Acceptance without a consequence is a statement of intent. Acceptance with a consequence is an agreement.

How is what the automation brings you measured?

The savings can only be proven if the baseline was measured before the start. Without that figure, you'll later have two opinions and no number.

Baseline means: how often the process occurs per week today, and how many minutes it costs you or your team each time. You record these two numbers before anything is set up.

You do the math yourself. Frequency times duration times hourly rate is the amount the process costs you today. The same calculation after setup shows you the difference.

A worked example, not a measurement: suppose an appointment request comes in 20 times a week and ties up six minutes each time. That's 120 minutes, two hours a week. Two hours times your hourly rate times the weeks in a year is the price of this one process. Plug in your own numbers and you have your baseline.

Why before the start? Because after setup, you only remember the old state. Memory rounds. Your team will then estimate the previous effort sometimes higher, sometimes lower, depending on who's asking. A number written down beforehand stands.

So ask your provider three things: Who measures? When is it measured? And what follows if no savings show up?

The first question settles whether both sides recognize the same basis. If only the provider measures, you check their number against your own. If nobody measures, you lack the basis for every later conversation about value.

With me, measuring the baseline is part of the setup. And the third answer is fixed: if no savings can be proven after three months, the success-based share for that process is waived permanently. How your provider handles it is their business. That they handle it is yours.

Who notices an error first?

In the worst case your customer, in the best case the system itself. Ask how an error reports itself, who it reaches, and who fixes it within what timeframe.

A process a person used to handle had a built-in check: the person saw when something was off. As soon as the process runs on its own, you lose that pair of eyes.

An automation without error reporting therefore doesn't run reliably. It runs unobserved. You only see the difference once a request has sat unanswered for three days.

The causes often lie outside the automation itself. An access expires. A program the process is connected to changes its interface. A customer enters something in a field nobody expected. That's not a flaw in the work, that's operation. So the question for your provider isn't whether errors happen, but how quickly you find out.

Have them walk you through a concrete case. The appointment confirmation doesn't go out: who finds out, by what route, after how many minutes? The answer shows you whether the provider has already built this case or merely thought about it.

Then keep asking. What happens to the request that got stuck when the error occurred? Is it caught up once the process runs again, or is it lost? For you, that's the difference between a delayed reply and a customer who never gets one.

The third sub-question concerns responsibility. Does the alert land with you, with the provider, or with both? And who acts then? An alert that doesn't trigger a task for anyone is just one more unread message in your inbox.

An error that reports itself costs you minutes. An error that stays silent costs you customers.

Who owns the data and the access?

You do, but only if the contract says so. Ask who holds which access and in what form you receive your data when the collaboration ends.

Two states sit side by side here: you use a system, or you own it. In the first case, your process ends with the contract. In the second, you take it with you.

You won't notice this in day-to-day operation, because as long as everything runs, both states feel the same. The difference shows on the day you want to switch, expand or end. That's why you settle it beforehand.

Go through the access points one by one. Whose name are the accounts for the connected programs in? Who knows the passwords? Who can lock or reassign access? If any of these sits with the provider alone, your process depends on their availability.

Then ask specifically about the last day. Do you get all your data handed over in full? In a format you can open without the provider? Do the processes remain operational on your side?

These processes contain your customers' data: names, requests, appointments. You bear the responsibility for it, even if someone else set up the system. Where the data sits and who can see it is something you should be able to say in one sentence.

For my partnerships I've fixed it like this: control of the server stays with you, I have no server access and work through the interface. On termination, all data is exported in full.

Your provider may solve it differently. You should just know how, beforehand.

How long are you bound?

The notice period tells you that, not the sales conversation. Ask about the minimum term, the notice period, and what happens to running processes on the last day.

A long commitment isn't automatically a disadvantage for you. But it shifts the risk: the longer you're bound, the more you need to know before you sign.

The logic behind it is arithmetic. With a one-month notice period, a wrong decision costs you one month. With a two-year minimum term, it costs you two years of base fees, no matter how the process develops. Your diligence before signing should grow in step with the term.

Watch three places in the contract. The minimum term tells you the earliest you can leave. The notice period tells you how long it takes from decision to end. The renewal clause tells you what happens if you miss a date.

You may be thinking: a good provider doesn't need a lock-in. That's exactly what you can check. My partnerships have no minimum term, and either side can terminate with 30 days' notice to the end of the month.

Connect this question with the previous one. A short notice period does you little good if your processes end on the last day and your data stays with the provider. Only notice period and handover together show how free you really are.

The rule behind it applies to every contract you sign: whoever keeps you with results doesn't need a term that keeps you.

What does the first year cost you in total?

You only know once you add up three items: setup, ongoing operation, and everything that depends on results or usage. An offer that names only the first item shows you a third of the bill.

Ask for the total for twelve months as a single figure. Then ask which parts of it are fixed and which can move.

Fixed parts are the one-time setup and the monthly base fee. Variable parts hang on something that only shows in operation: the number of transactions, the usage of connected services, computing power, or the result achieved. Also ask which of these items you pay to third parties and which to the provider.

For the variable parts, the formula counts, not the estimate. What does the amount depend on, who establishes the basis, and where is the cap?

A success-based share isn't a disadvantage for you. It ties the provider to your result. But it presupposes that the measurement from the second question is in place. Without a recorded baseline, you'll end up calculating with a number only one side knows.

Also ask what happens to your terms if the provider changes their prices. Do new prices apply to you too, or only to new customers? With me, price changes apply only to new partnerships. This one line decides whether your bill still holds in year two.

Then set the annual total next to your baseline. On one side is what the process costs you per year today. On the other, what the automation costs you in the first year. Only both numbers side by side show you whether you're looking at an expense or an investment.

What the six answers show you about the provider

The answers themselves are half the information. The other half is how they arrive.

A provider who knows their acceptance criteria, their measurement and their termination rules answers you in sentences. One who develops them during the conversation answers you in intentions.

You hear the difference in the verbs. "The error is reported by email to you and to me" is a sentence. "We'd find a solution together" is an intention. Both can be sincerely meant. You can only hold them to the first later.

Write the six questions on a sheet of paper and ask every provider in the same order. That way you compare answers instead of impressions.

Note the answers verbatim, right there in the conversation. Afterwards, ask for them to be included in the offer. A provider who commits to that unprompted shows you how they'll work with you in operation too.

Expect that not every answer comes immediately. That's not a reason to rule someone out. What matters is what happens next: if the answer follows in writing within the promised timeframe, you've learned something about reliability before you've committed a single euro.

Clarity before you sign costs you an hour. Clarity after you sign costs you months.

The questions are only as sharp as the person asking them

All six questions presuppose that you know what you want: which result, to what degree, by when. No provider delivers that. You bring it.

You can see it in every single question. Acceptance demands that you can name the result. Measurement demands that you know your current effort. The annual calculation demands that you know what the process is worth to you. If one of these decisions stays open on your side, the provider's answer stays open too.

That reaches far beyond this one job. Your business grows exactly as far as you do: it executes what you decide clearly, and it delays what you leave open.

An automation just makes this mechanism more visible. It executes exactly what was specified, every time, without asking. Your clarity is multiplied, and so are your open points.

That's why the job starts with you, not with the provider. First become the person who knows what they're commissioning, then commission, then have the result.

That is exactly where the Challenge comes in: four days, free, the entry into Become → Do → Have. You'll find it at impruvement.com/en/challenge.