The two-day audit: what we put a figure on, and why

Before building anything, I put a figure on it. Two days, €1,900. I watch what your teams do by hand, and I put a price on what it costs you.

Why put a figure on it first

You can start a project with the solution: an application, a tool, an agent. Then you wonder what it will bring in.

I prefer the reverse. First, what the process costs you today. Next, what the tool would save. And only then, what the tool would cost.

The other way around, you end up justifying a project that has already been decided. The figures come in to reassure, not to decide.

What I look at for two days

For two days, on site or remotely, I watch what your teams do by hand. For example:

• the Excel files that get filled in, copied and sent back;
• the approvals that go through email, and the reminders that come with them;
• the retyping from one tool to another;
• the reports rebuilt by hand every month.

I'm not looking for places to put technology. I'm looking for where the time goes, and therefore the money.

What we put a figure on

At the end of the two days, you have four things.

• What the process costs you today. In euros, not in impressions.
• What the tool would save. How much it costs today, how much it would cost tomorrow.
• A written scope. What's in, and what's not.
• A fixed price. Not a range. A price.

The written scope protects both sides. You know what you're buying. I know what I'm delivering. And nobody finds out halfway through that they weren't talking about the same thing.

The math is quick

Let's take an example. A company knows it loses €15,000 a month. Someone comes along and says: "I cost €15,000, once, and the problem goes away." The math is quick.

That's exactly what the audit sets out to establish. On one side, a cost that repeats every month. On the other, an investment you pay once. When both figures are on the table, the decision no longer needs a long debate.

The example is deliberately simple. In a real process, the cost hides in hours of data entry, reminders, errors to fix. The audit is there to add them up.

Without these two figures, you discuss a price. With them, you discuss a gain.

And if the gain doesn't justify the project

Then I tell you.

It's not modesty. It's math. A project that doesn't bring in enough will cost you more than the audit. Better to know after two days.

To be honest, it's also what makes the other figures credible. If I never said no, my "yes" would be worth nothing.

Then, how we build

If the gain is there, the build follows three rules.

• In batches, with a demo every week. You see the tool take shape, and your feedback comes in as you go.
• Acceptance testing on a real case, never in production. Nothing goes out to your customers until it's proven.
• You stay the owner. The tool lives in your Microsoft 365 space. You receive the documentation, the user guide and the quick reference guide, and your teams are trained.

What this means for you

Before launching a tool project, ask yourself the questions the audit asks.

• Do you know what the process costs you today, in euros?
• Do you know what the tool would save, as a number?
• Do you have a written scope, or just an idea of one?
• Do you have a fixed price, or an estimate that will move?

If an answer is missing, that's where to start. A well-costed project gets decided quickly. A poorly costed one gets debated for a long time.

Part of the answer is sometimes in what you already pay for: zero software purchased. An example of a hidden cost, consolidation by files: the Excel consolidation that ends in a six-month debate. The audit is detailed on the page Two days to put a figure on the gain, and delivered projects are in the case studies.

First we put a figure on what the process costs you. If the gain doesn't justify the project, I tell you.