Selling Outcomes Instead of Hours: How an MSP Quotes an Automation Project

Outcome-based quoting is pricing a piece of work by what it changes for the client rather than by the hours it takes you to do it. For an MSP moving into automation it is the single biggest change in how you sell, and it is the one that most affects whether the work is worth doing.

An MSP's whole commercial habit is built on time. Tickets are logged by the hour, projects are scoped in days, and a quote is usually an hourly rate multiplied by an estimate. That works for work the client can already picture, such as a server migration. It works badly for automation, for a reason that is easy to miss: the better you get, the less you earn.

Why hours quote against you

A workflow that takes an experienced engineer an afternoon to wire used to take a week. If you quote by the hour, your price falls every time you improve, and the client who sees a one-afternoon invoice for something that saves them a day a week will, reasonably, wonder what the fuss was about.

The hourly quote also hides the part that carries the value. The afternoon of building is the smallest piece. The larger pieces are finding the right process in the first place, designing it so it survives contact with real data, and putting a person in the right place in the loop. We wrote about that first choice in the post on which automation your client will pay for. None of it shows on a timesheet.

What the client is buying

Put the question the other way. What does the owner get at the end? Usually it is one of three things: hours back each month, a mistake that stops happening, or a delay that disappears. Each can be written in the client's own terms, and each can be checked.

That gives you a sentence to quote against. Not "build a workflow that routes new enquiries", but "new enquiries get a reply the same day, with nobody having to remember to send it". The first describes your work. The second describes their result, and it is the one an owner can say yes to.

Three parts to the quote

Split the quote into three, because they carry different risks.

The discovery is the first part, and it should be priced separately, even if it is small. It produces the picture of how the work actually runs and the ranked list of what is worth changing. If you give it away, you teach the client that the thinking is free, and the build becomes the only thing they feel they are paying for.

The build is the second, and it can be a fixed fee, because by now you know what you are building. A fixed fee is safe only after discovery. Before it, you are guessing.

The running is the third, and it is the part MSPs forget. A live automation needs checking, owning and sometimes fixing, and it carries its own running costs. The first month after go-live and the question of what happens when usage doubles are both worth settling in the proposal and not afterwards.

Putting a number on the result

The temptation is to promise a saving. Don't promise one you cannot back. Say what the process costs today in hours a month at the client's own rates, say how much of that you expect to remove, and show the working. If the client disagrees with an assumption, you can change it in front of them, and they will trust the rest of the number more for having been allowed to argue with it.

A conservative number you can defend is worth more than an impressive one you cannot.

Where the hourly quote still belongs

There are cases where the old way is right. A small, well-understood job with a clear edge, such as connecting two systems the client already uses, is a fair thing to quote by the hour, and dressing it up as an outcome would be theatre. The same goes for the first piece of work with a new client, when neither of you knows enough to price a result. Do it by the hour, do it well, and use what you learn to quote the next one properly.

What changes in the conversation

The meeting stops being about your effort. The owner stops asking how long it will take and starts asking what happens if it does not work, which is a better question and one you should have an answer to before you walk in. Decide in advance what you will do if the result is not reached: fix it at your cost, extend it, or agree the target was wrong and reset it.

That last option is not weakness. It is what a consultancy does that a supplier of hours does not.

Once you can quote this way, the work looks like a service line rather than a series of jobs, which is the point of the post on what an automation service line actually contains. And it sets up the quarterly conversation about the business that comes after it.