For the person making the case

You're not the one who signs off. You're the one who has to explain why it matters.

The MD asks where things stand, and the honest answer is "ask whoever holds it in their head." You can see the problem clearly. You just don't have the authority to fix it on your own β€” so you need to make it land with the person who does.

πŸ‘€
The MD

Signs off. Cost-conscious. Sceptical of tech promises β€” especially if the business has tried software before and dropped it.

⚑
You're here The champion

Can see the gap. Manages the project if it goes ahead. Has to build the internal case β€” without a budget of your own, and without it sounding like you're just asking for more software.

πŸ—οΈ
Us

Can help you put the numbers together. Happy to talk to the MD directly when you're ready β€” or stay in the background while you run the conversation.

If this is you

Any of these sound familiar?

You get asked where a job's at, and the real answer is in someone else's head β€” not the system.

You know exactly where the gap is. You just don't have the authority to fix it on your own.

You've raised this before and it didn't land β€” because "we need better software" isn't a business case.

You're the one who'll actually use whatever gets bought, but rarely the one in the room when it's decided.

The MD's main concern is cost β€” and "it'll save time" isn't convincing enough on its own.

You want to get this right, not just get it approved β€” because you'll be the one living with whatever's implemented.

The real problem

This isn't about you being disorganised.

The reason everything routes through you β€” or through whoever your equivalent of "Dave" is β€” isn't because your team is bad at their jobs. It's usually the opposite.

The person holding it all in their head is holding it because they're good at it. The business has come to rely on that. And that's the structural risk worth putting in front of the MD: the business is one person's availability away from losing visibility over what's actually happening.

That's not a personal failing. It's a process gap β€” and it's the kind of argument that lands with a cost-conscious MD, because the cost of it is real whether or not it shows up as a line on a P&L.

The business that answers first usually wins the job. Right now, the speed of your quote depends on whoever can check what's free β€” not on the customer's urgency.

β€” A framing worth using in that conversation

Two things that actually help

Free. No email required. No pitch at the end.

Both of these are built to be genuinely useful whether or not you ever talk to us. If the honest answer is "not ready yet," they'll say that too.

Self-audit

See where it's actually costing you.

A short, honest assessment across the six areas that usually matter in hire β€” speed to quote, availability you trust, off-hire follow-through, key-person risk, following up, and what the MD can actually see.

Takes around 10 minutes. No login, no email gate. At the end you'll have a clear picture of where the real gaps are β€” in plain terms you can share.

Start the audit β†’

Results are yours to keep. We don't see them unless you choose to share them.

Business case builder

Turn "this is slowing us down" into something the MD can act on.

Costs the status quo in plain terms β€” what slow quoting, missed off-hire charges, and key-person dependency are likely costing the business per year. Generates a neutral, editable document you can take into that conversation.

Built to be honest: if the numbers don't make a strong case, it'll tell you that, and suggest what to address first before revisiting the software question.

Build your case β†’

The output is a Word document you own and edit. Cloudtal's name appears only in the footer.

Preparing for the conversation

The objections worth being ready for.

Most MDs in hire have seen a tech project go wrong. The scepticism is earned. These are the questions that tend to come up β€” and the honest answers to them.

We tried something like this before and it didn't stick.

Usually that's a process problem, not a software problem. The tool got dropped on a workflow nobody had written down, so nobody could tell if it was working. That's a different problem β€” and it's fixable before anything is built.

Is this the right time? We're busy.

The gap costs more when you're busy β€” more quotes to manage, more chances for a job to fall through the cracks. The right time to fix a process is before it becomes the ceiling on how much you can take on.

Can't we just do this ourselves?

Some of it, yes. Generic Salesforce setup is well-documented. The hire-specific part β€” availability tracking, ops system integration, hire cycle workflows β€” is where generic CRM has failed hire businesses before. That's the bit that needs someone who's built it.

What does this actually cost?

Depends on scope, and we won't pretend otherwise. What we can say: we start small by design β€” one measurable piece, proven, before the next. You're not betting everything on a single go-live.

Want to talk it through before you take it to the MD?

We're happy to have that conversation β€” with you, or with both of you together. No pitch, no pressure. Just a clear picture of what's possible and whether we're the right fit.