A business case is a structured argument for why your agency should invest in a new system. It outlines the problem you're trying to solve, the cost of not solving it, and how the proposed solution delivers a return on investment.
In agencies, the business case for a management system typically centres on three things: improving project profitability, increasing team utilisation, and reducing the time spent on manual reporting and admin.
A good business case doesn't lead with technology. It leads with the business problem, quantifies the cost, and presents the solution as the most logical way to fix it.
It doesn't have to be a 20-page document. It could be a formal proposal, a slide deck, or a five-minute conversation backed by the right numbers.
The most common mistake is building a business case alone. If you walk into a room as a lone voice with an opinion, you're easy to dismiss. If you walk in with three people who've all seen the problem from different angles, you're presenting a consensus.
Before you write anything down, have informal conversations with the people who feel the same pain:
You're not asking them to commit to anything. You're asking, "Do you see the same problem I see?" When they say yes, you've got an ally. When three of them say yes, you've got a movement.
These conversations also give you language. When the ops lead says "I spend every Friday afternoon chasing timesheets instead of managing the team," write that down. Real quotes from real people are more persuasive than any statistic.
Tip: When you present the business case, mention who else you've spoken to and what they said. "I've talked to Sarah in ops, James in finance, and the project team. They're all seeing the same thing." This changes the dynamic from "one person wants new software" to "multiple people have identified a problem that needs solving."
The moment you say "I think we should buy new software," the person you're talking to starts calculating cost. Their brain goes straight to "how much?" before you've explained why.
Start with the problem instead. Describe the situation the agency is in right now. Make it specific. Make it concrete.
Don't say: "We lack visibility across the business and our processes are inefficient."
Say: "Right now, we don't know whether a project is profitable until after it's finished. Month-end reporting takes two days because we're pulling numbers from three different systems and reconciling them manually. And when we need to make a decision about capacity, we're guessing."
The first version is abstract. The second is a story that decision-makers can picture.
Pick the three or four challenges that connect directly to the agency's strategic priorities:
Frame each problem as what it's costing the agency, not what's broken. "We can't see project profitability" becomes "We don't know we've lost money on a project until it's too late to do anything about it." The first is a system gap. The second is a business risk.
This is where most business cases fail. They describe the problem well, then wave vaguely at the benefits. Your FD needs numbers. Not precise numbers. Reasonable numbers.
Here are three ROI calculations that work for agencies:
If you have 20 people charging at £90 per hour, recovering just 15 extra minutes per person per day adds up to roughly £190,000 a year in recoverable revenue.
Most agencies underestimate non-billable time by 20-30%. When people don't track time accurately, or when the system makes it hard, revenue leaks. Fifteen minutes per person per day doesn't sound like much. Nearly £200k per year sounds like a lot.
The industry average agency utilisation rate is around 65%. Agencies using an integrated management system typically achieve 75%. For a 20-person team at £90 per hour, that 10% gap represents roughly £313,000 a year.
Overservicing by just 10% on each job is the equivalent of working for free from mid-November until the end of the year. Five weeks of free work. Every year. Most agencies know they overservice. Few have quantified what it actually costs.
This isn't just an agency problem. Research by McKinsey found that businesses using data to make effective decisions and optimise processes are 19 times more likely to be profitable. Most agencies know this intuitively. The business case makes it concrete.
You don't need all three. Pick the one that's most relevant to your agency's situation and build the case around it. One compelling number is more persuasive than five vague ones.
"Since implementing Synergist, we've seen admin time reduced by about 20%, and in our most recent financial year, gross profit increased by 25%."
Once you've established the cost of the problem, the investment in solving it looks different:
Tip: Don't over-promise. Present a conservative estimate and let the FD do the maths themselves. "Even if we only recovered half of that, we'd be looking at £95k a year" is more credible than claiming the full amount.
This is where most business cases stall. The problem is acknowledged. The numbers are compelling. But the response is "let's look at this next quarter." Every quarter.
You need a genuine reason for now, not artificial urgency:
You're not creating false urgency. You're making the cost of waiting tangible.
Synergist is time saving, cost saving, easier and more efficient. It’s streamlined everything. As a business, we wish we’d turned to it years ago.
Every decision-maker has the same concerns. If you wait for them to raise them, you're on the defensive. If you name them first, you've taken the fight out of the conversation.
"It's going to be disruptive"
This is the number one fear. The agency is running. Clients need serving. Nobody wants three months of chaos.
Address it directly: a proper implementation partner configures the system around how you already work, not the other way around. It's phased, supported, and designed to minimise disruption.
"The team won't use it"
This is really a change management question, not a technology question. When the system genuinely makes people's lives easier, they adopt it because they want to, not because they're told to. Proper onboarding includes dedicated training and ongoing support to make sure adoption sticks.
"We've managed without one so far"
You have. And the workarounds you've built are a testament to the team's resourcefulness. The question isn't whether you can manage without it. It's whether managing without it is holding you back from where you want to be. Spreadsheets worked when you were 10 people. At 25, they're creating work. At 40, they'll be the thing that stops you scaling.
"What if we choose the wrong one?"
This fear creates paralysis. The answer: choose a provider that demonstrates it understands your world, not just one that has a long feature list. Ask for references from agencies your size. Ask about onboarding and ongoing support. The right system comes with people who'll make sure it works, not just a login and a help desk.
It's also worth asking whether the system can grow with you. An agency at 25 people today might be 50 in three years. The right system scales without needing to be replaced, so you're not having this conversation again in two years' time.
Here's our guide on how to choose the right agency management system.
Tip: The most powerful way to address objections is to share what happened at other agencies. "I spoke to [reference agency] who had exactly the same concern. They said the first two weeks were an adjustment, but by month two they couldn't imagine going back." Real stories neutralise abstract fears.
If you need to present this formally, here's the structure:
| Section | What to include |
|---|---|
| The core problem | 3-4 specific, concrete challenges. Use real examples and quotes from colleagues. Frame as cost to the business, not system gaps. |
| The impact | One or two numbers that quantify what the current situation is costing. Use the recoverable time, utilisation gap, or overservicing calculations. |
| The proposed solution | What the system does, in plain English. Focus on outcomes: "We'll see project profitability in real time" not "real-time dashboard functionality." |
| The investment and return | Annual cost, per-person-per-month cost, and expected ROI. Present conservatively. |
| Why now | The cost of delay. The growth trajectory. The fact that it gets harder to implement as you scale. |
| The risks and mitigations | Disruption, adoption, choosing wrong. Name them and explain how each is addressed. |
| Who else supports this | Name the allies. Quote their concerns. Show this is a shared view, not a solo campaign. |
| The next step | Frame the next step as a conversation, not a commitment. See 'Making it easy to say yes' below. |
Don't end with "so should we do it?" Make the next step feel manageable, even when the commitment is significant:
Suggest a conversation, not a decision. "Can we set up a call with the provider so they can understand our setup and answer questions directly? No commitment, just a conversation."
Offer to bring the provider to the stakeholders. "If our FD has concerns, they're happy to jump on a call and talk through the numbers directly."
Frame the decision as solving a problem, not buying software. "We're not asking to buy a system. We're asking to fix a problem that's costing us £X a month."
Don't give up. Ask what would need to be true for them to say yes. "What would you need to see?" or "What would make you more comfortable?" These questions surface the real objection, which is almost never "we don't want this." It's usually "I'm not convinced yet" or "I need to see the numbers" or "the timing feels wrong."
If the answer is genuinely "not now," be gracious. Plant the seed. Come back in three months with an update. People often need to hear something multiple times before they act on it.
As short as your audience needs it to be. A one-page summary with the problem, the cost of doing nothing, and the proposed next step is often more effective than a detailed report. Decision-makers rarely read past page three. If they want more detail, they'll ask for it.
Speak their language. FDs don't respond to features or demo highlights. They respond to cost, risk, and return. Lead with what the current situation is costing (use the calculations in Step 3), frame the investment per person per month rather than as an annual lump sum, and present conservative estimates. Let them do the maths.
Yes, but it's harder. Focus on getting allies in operations and project management first. Build enough internal consensus that the FD is responding to a shared view rather than a solo pitch. If possible, frame your initial conversation with the FD as asking for their input on the numbers rather than asking for approval. People are more receptive when they feel consulted than when they feel sold to.
Don't treat it as final. Ask what would need to change for the answer to be different. Often the objection is about timing or confidence, not the idea itself. Come back in three months with updated numbers or new evidence. Many successful business cases succeed on the second or third attempt, not the first.
Only if your stakeholders specifically ask. A business case that compares three systems shifts the conversation from "should we solve this problem" to "which software should we buy," and that's a different, slower decision. Keep the focus on the problem and the ROI. The software evaluation can happen once you've got a yes in principle.
Use conservative estimates based on industry benchmarks and be transparent about the assumptions. FDs respect honest ranges more than precise claims. "Based on our team size, we're likely losing between £3k and £8k a month" is more credible than a single number presented as fact. Let them stress-test the assumptions themselves.
See how Synergist connects your projects, people, and financials in one place. We'll tailor the demo to what matters most to you.
