What implementing agency management software really involves

The work grows, the spreadsheets multiply, and at some point nobody can say with any real confidence which jobs made money. You put off doing something about it, until putting it off starts costing more than fixing it.

So you start looking for agency management software. Demos, shortlists, a spreadsheet comparing features. That's where all the attention goes, and it's the easy bit. Then comes the part nobody demos: actually putting the system into your agency. 

It's a change management project, and it's usually bigger than people expect.

The agencies that get the most from a new system are the ones who knew what it would take before they started.

So this guide sets out what actually happens. The work involved, how much of your team's time it needs, who has to be in the room, and the decisions only you can make.

What actually happens when you implement agency software

It looks much the same whichever system you choose. Eight things, running in roughly this order. Discovery, design, configuration, data, training, launch, embedding, then review and refine. Most of it has very little to do with the software.

Discovery

Someone sits with each part of your agency and works out how you actually run. How you win work, how you quote it, how you resource it, how you deliver it, how you invoice it, what you report on, and everything in between. This is a listening exercise. Done well it surfaces what works, what doesn't, and all the workarounds nobody mentions until someone asks.

Design

Then you decide what good looks like. Which processes stay as they are, which get improved, and which get dropped. This is where the quality of everything downstream is decided, and it is the step agencies most often skip. Skip it and you rebuild your existing workarounds inside a new system, then wonder why nothing got better. Design should change something. If what comes out of it is just a description of how you already work, the step has not really happened.

Configuration

Your job structures, your workflows, your processes, your approval rules, your reporting. This is where a system either fits how you work or quietly forces you to work its way. Most of the difference between agencies who love their system and agencies who tolerate it is decided here.

Data

Clients, contacts, suppliers, open jobs, historic financials. Deciding what comes across and what stays behind is a real piece of work, and it is almost always more than people expect. A system is only as good as what is in it.

Training

Your finance lead and your account managers need completely different things, and generic training is the fastest route to a system nobody uses properly. Expect questions the training never covered, usually around week three. Name someone in each team people can go to, and make sure that person has someone to ask too.

Launch

The day you switch over, and it takes more planning than it usually gets. Pick the date deliberately, because the start of a month or a financial period is far cleaner than the middle of one. Decide what happens to jobs already in flight, whether they move across or finish where they are. Decide how long the old system stays available and who still needs access to it. Make sure the people who can answer questions are free that week, not on holiday or in a pitch. Then treat the first month-end as the real test, because that is when you find out whether the configuration was right.

Embedding

Go-live is not the finish line. The weeks after are when new ways of working either take hold or quietly don't, and that needs someone actively watching rather than hoping. Change models call this refreezing: the stage where a new way of working stops being the new way and becomes simply how things are done. It is the step most often skipped, because by then the project looks finished. Keep saying why the change happened, keep the benefits visible to the people doing the work, and make a point of noticing what is going well rather than only chasing what isn't.

Review and refine

You will not get it right first time, and a good implementation does not assume otherwise. A few weeks in, the gaps show. A workflow that made sense in a workshop turns out to be clumsy in practice, a report is missing the one field everyone wants, a job type nobody uses. Build the feedback loop in from the start. Ask the people using it what is getting in their way, and fix it while the attention and the expertise are still on the project. Then act on what you hear. Asking for feedback and doing nothing with it is worse than never asking.

None of this happens by itself. Every one of those eight things takes real time from real people. The next question is whose.

Who should run your software implementation?

All of that work has to be done by someone. The discovery, the design decisions, the data migration, the training, the chasing people to actually use it. It is a real job for the length of the project, not something that fits around one. There are three ways to cover it.

You do it yourself

Cheapest on paper, and nobody understands your agency better. Most agencies have someone who knows about this sort of thing, and it is tempting to hand it to them. But it is not their job. Doing it properly means pulling them off the work they were hired for, often for weeks. And even if they have used a similar system somewhere else, they will not automatically know this one, so they will be learning while deciding, which is the worst way to do either. Workable if you are small, your setup is simple, and someone genuinely has the weeks free. Beyond that it is the route that goes wrong most often, and it goes wrong quietly. You do not find out at go-live. You find out months later, when the reports do not reconcile, nobody trusts the numbers, and unpicking it costs more than doing it properly would have.

You bring in a project manager or independent consultant

Someone whose job is this project and nothing else. That helps if you want one person holding the plan together, and especially if you have other changes running alongside it. The limit is product depth. Unless they specialise in the system you have chosen, they will be learning it alongside you, so you are buying process expertise rather than product expertise. Ask how many implementations they have actually run, and how many of those were in agencies. Someone on their second is a very different proposition from someone on their fiftieth.

The software company does it

You get people who have done this many times and know what works across hundreds of agencies, not just yours. They can also tell you what hasn't worked for other agencies, which is worth as much as the configuration itself. The trade-off is that it costs money, and the quality depends entirely on whether their consultants know agencies or just know software. What you do get is continuity. They are still there in month nine, because you are their customer rather than their project.

The question worth asking is not which is cheapest. It is which route gets you the best result, in the best time, for the money.

There is also a reasonable principle at work here. When a client comes to you, they are buying expertise they do not have in house. You would not expect them to download design software and produce the work themselves. The same logic applies to configuring a system you will run your business on.

Who needs to be involved, and how much of their time it takes

More people than you think, and more of their time than you have budgeted.

The structure that works is a change team. The project owner plus a representative from each department, meeting regularly through the build. Not a committee, a working group. Each person speaks for how their team actually operates, takes decisions back to them, and brings the objections forward early rather than the week after go-live. It also means the new way of working is argued for by someone's own colleague, which lands very differently from an announcement by management.

A new system will ask you questions your agency has been avoiding. How do you structure a job. What counts as billable. Who signs off a quote, and at what value. What is a project and what is a retainer, and how do you handle the ones that are both. What does a cost rate actually include. Which of your reports do you genuinely use, and which do you produce because someone once asked for them.

Most agencies have been running on habit, workarounds and a few spreadsheets that one person understands. That works until you try to codify it. Then every fudge has to be resolved, because a system cannot hold two contradictory answers at once.

This is uncomfortable, and it is also the single biggest source of value. The clarity you get from making those decisions properly tends to outlast the software. Whoever runs your implementation should surface them and help you decide. They cannot make the calls for you.

Here is roughly what it takes for a mid-sized agency. Scale it up or down for your size and how much you are changing.

The leader row is the one agencies cut first and shouldn't. The moment implementation looks like an ops side project, it becomes one.

End to end, most agencies are looking at two to four months from kick-off to running properly on the new system. The effort is not spread evenly. Discovery and design are front-loaded and intense, the middle is quieter while configuration happens, and launch spikes again.

Which raises the question nobody asks early enough. What gives while this is going on? If your ops lead loses a day a week for three months, that day comes from somewhere. Decide in advance whether it is a slower month on delivery, freelance cover, or simply taking on less new work during the build. The agencies that struggle are the ones who assumed it would absorb into the margins of everyone's week.

And check the calendar before you commit to a date. If implementation collides with budget season, a big pitch or a major delivery, something will give.

All at once, or in phases

This question splits leadership teams, and there is no universal right answer. There are real trade-offs on both sides.

Two things are easy to miss. Spreading the work over six months instead of six weeks does not reduce the mental load, because every process question still becomes a question about the new system. And a phased rollout gives rumours time to travel. One vocal person reminiscing about the old way can shape expectations before the next group has even started.

There is a third option worth knowing about. Instead of splitting by department, split by client. Run a handful of clients in the new system first, with everyone involved, then add the rest as people find their feet. The whole agency learns together, which avoids the rumour problem, but on a small enough surface that mistakes are cheap.

As a rough rule, if your work is fairly uniform and your agency is small, going in one hit usually wins. The more complex your structure, the more a phased approach earns its keep.

Whichever you choose, back it properly and make sure people can see the end of it. The worst implementation is the one that never quite finishes.

Most of the work is change, not software

Most system rollouts don't deliver what was expected. The reason is almost never the software.

Picture how this usually lands. A calendar invite appears in someone's diary for three sessions on a system they have never heard of, run by someone they have never met, in a week that was already full. The mumbling starts before the first session does. No capacity. Not another thing. We're always the last to know.

John Kotter's research put the odds of organisational change succeeding at around 30%. That number should give anyone pause, because it means the default outcome is not success. It is why two agencies can buy the same system and end up in completely different places.

The people side is predictable enough to plan for. Old habits have to be challenged before new ones take hold. What matters is accepting that resistance is normal, not a sign something has gone wrong. Expect to hear that you have never done it like that before, and that someone tried something similar once and it didn't work. Both are usually true. Neither is a reason to stop.

Four things make the difference in practice.

Explain why, not just what. Not everyone in your agency has a commercial focus. Buying a system and telling people to start logging time is an instruction, not a reason. Tell them what it is meant to fix.

Explain what's in it for them. The agency reason is not their reason. A system is only as good as the data going into it, and your people are the ones putting it there, so tell them what they get back. Fewer people chasing them for updates. A job going over spotted before the client notices. Someone seeing the nine-hour days before they burn out. Framed that way it reads as support rather than surveillance.

Keep communicating. Most leaders brief heavily before launch and go quiet afterwards. That is exactly backwards. The questions arrive once people are actually using it, and they need to hear from you, not just from whoever is running the training.

Celebrate the wins early and often. Change doesn't happen in one go, it happens in steps. The first clean month-end. The first report nobody had to build by hand. The first week everyone's timesheets were in on time. Calling those out keeps momentum going once the novelty has worn off.

The six-month problem

A new system is a novelty for about six months. Then the novelty wears off, and old habits come back.

This is the failure mode nobody plans for, because by six months the project feels finished. Whoever set it up has moved on, the training is done, everyone has a login. Meanwhile someone has started keeping their own spreadsheet again, a team has quietly stopped using the approval workflow, and timesheets are going in on Friday afternoon from memory.

Nothing dramatic happens. The system just slowly stops reflecting reality, and the reporting you bought it for stops being trustworthy. Once you cannot trust the numbers, you stop looking at them.

The fix is unglamorous. Decide in advance who is checking that the new way is holding, what they are looking at, and how often. Build it into a job description rather than leaving it to goodwill. And expect to need outside help past go-live, not just during it, because the person who set it up is the only one who knows what good looks like.

Then there are the people who weren't there. Six months in you hire three more, and nobody has thought about how they learn the system. They pick it up from whoever sits nearest, which is how one person's workaround becomes everybody's. Decide who inducts new starters, and on what, before you need to.

If the people who set it up disappear at go-live, this is the gap you are inheriting.

What to ask before you choose new software

Ask these of everyone on your shortlist. The answers will separate them faster than a feature comparison.

1. Is implementation quoted or estimated? A fixed quote before work starts means someone has scoped it. An estimate means the risk is yours.
2. Who actually does the work? Their own team, mine, or someone else's. Either way, name the people and ask what else they have on.
3. What happens after go-live? Specifically: who is still involved at month three, month six, month twelve, is that included or extra, and what happens when we hire someone new a year from now.
4. How much of my team's time will this need, and from whom? Anyone who has done this often can tell you. One who waves it away has not.
5. Do your consultants know agencies, or just your software? Ask what they did before. The answer tells you whether they will challenge your processes or just replicate them.
6. What does a bad implementation look like, and what causes it? Any honest supplier has seen one. The ones who claim they haven't are the ones to worry about.
7. Who runs the training, and who writes the guides for our team? If the answer is a help centre, some videos and a champion you nominate yourself, that is self-service with a support desk attached. It may still be the right choice. Just price it as what it is.
8. Who owns change management and adoption? Someone has to get fifty people to work differently. Find out whether that someone is you, before you sign rather than after.

If they cannot answer these clearly, that is your answer.

The short version

Implementing agency management software is a change project with some software in it. Plan for the people, not just the platform.

The work is real whichever system you choose and whoever you buy it from. The only question is whether it is scoped, priced and owned from the start, or whether it lands on someone in your agency who already has a full-time job.

Go in with your eyes open and you get a system that reflects how you actually work, numbers you trust, and decisions made on evidence instead of instinct. Go in expecting to plug it in and switch it on, and you will spend the next year wondering why it never quite delivered.

The difference is not the software. It's how you go about putting it in.