The Discovery Call for an Automation Project: Seven Questions an MSP Should Ask

A discovery call for an automation project is the first conversation with a client's owner, held before any tool is mentioned, to find out whether there is a process worth changing and whether you are the right person to change it. It decides whether the project is worth quoting. Most MSPs treat it as a sales call. It works better as an interview.

The difference matters because the owner will tell you what they think you want to hear if you start by selling. Ask first and the answers are more honest, and more useful for the quote.

The seven questions

What took the most time in your business last week that you did not enjoy? Start here, because it is concrete. Ask for last week, not in general. People remember last week.

Who does it, and how many people does it pass through? The number of hands is the best signal of a process worth fixing. The more handovers, the more places for work to wait.

What happens when it goes wrong? This tells you the cost of failure, which sets how careful the automation has to be. It also tells you where a person should stay in the loop, which the post on the approval step covers.

What do you use to do it today? Systems, spreadsheets, inboxes. You are looking for what the automation would have to connect to, and for the thing nobody mentions, which is usually a spreadsheet one person keeps.

Has anyone tried to fix it before? A previous attempt is information. It shows you what the client thinks the problem is, and sometimes it turns up an automation that already exists and that nobody owns. That is a finding in its own right.

Who would have to change how they work? The automation will fail if the person whose job it was does not trust it. Name them now.

What would good look like in three months? Make them say it in their own terms: hours, errors, days. That becomes the sentence you quote against, as in the post on selling outcomes instead of hours.

What to listen for

Listen for the second and fifth answers more than the rest. A process that passes through four people and has been patched twice is a better candidate than a tidy one that merely annoys somebody.

Listen also for what the owner does not say. If every answer is about technology, you are talking to someone who thinks the problem is the tools. Gently steering towards the people and the handovers is part of the value you add, and it is the same shift described in the post on value-added AI.

What not to do

Do not pitch a tool. Do not promise a result before you have seen the process. And do not offer a number on the call. A number given on the spot is the number you will be held to.

After the call

Write up what you heard within the day, in the owner's words, and send it back with the one or two processes you think are worth a closer look. That note does two jobs. It shows you listened, and it is the start of the discovery you will price separately.

If the client agrees, the next step is to interview the people who do the work. A map built from those interviews gives you the ranked list that the rest of the project follows. In abi. an MSP gets five client maps free on top of its own, so the first one costs you the interviews and nothing else. The ranked list is also what you will bring to the first quarterly conversation, which the post on the virtual CEO conversation describes.

Where it goes wrong

The most common failure is a call that turns into a demonstration. The owner asks what the tool does, you show them, and forty minutes later you have a polite client who has seen a product and still has the same problem. If they ask, say you will show them after you understand the process, and mean it.

The second is taking the first answer. The process an owner names first is the one that annoyed them this week, which is rarely the one that costs the most. That is why the second and fifth questions matter more than the first, and why a short follow-up with the people doing the work is worth the time.

When to say no

Some calls end with a decision not to proceed, and that is a good outcome. If the process is trivial, the client will not change how they work, or the owner wants a tool and nothing else, say so. An MSP that turns down the wrong project is believed on the right one.