Marketing tools often go unused for reasons that are not primarily about the software. The recurring causes are no clear link between the platform and what the team is trying to improve, training that stopped after launch, a workflow that still allows the old way, poor integration with existing systems, and nobody owning the platform once the implementation project closed. Training is part of the answer, but it is not the whole strategy — most of these are operating problems rather than knowledge problems.
The moment this usually surfaces is a renewal. Somebody asks whether to keep paying for a platform, and nobody can say with confidence whether it is actually being used — or which parts of it are.
What follows is a scramble for evidence. Login reports get pulled. A few people are asked. The answers conflict, because some teams have built their whole process around it and others quietly went back to the shared drive and the email thread months ago.
Nobody made a decision to abandon the software. It just never fully arrived.
Three things get treated as one, and separating them makes the rest of this easier.
Adoption asks whether the platform has become the normal way the relevant work gets done. Utilisation asks how much of the capability that matters to you is actually being used. Value asks whether any of it has improved something — approval turnaround, rework, visibility, compliance evidence.
They come apart in both directions. A team can log in every day and still handle approvals in email, which looks like adoption and is not. Another team might use a narrow set of features and get exactly the outcome the platform was bought for, which looks like underuse and is not a problem.
Tools are often bought on features or price without a clear statement of what will change once they are in. If nobody can say what the platform is supposed to improve — approval turnaround, rework, visibility, compliance evidence — then nobody can tell whether it is working, and using it stays optional.
The teams that adopt well can answer one question before rollout: what does this let us do that we cannot do now, and how will we know.
Most implementations include training. Most training happens once, covers everything, and lands on people who have not yet used the system for real work.
Two weeks later they know the basics and none of the capability that made the platform worth buying. The features that would justify the licence go unexplored, not through resistance but because nobody came back.
Tools bought without checking how they connect to what you already run create more work rather than less. If people have to re-enter the same information in two places, they will pick one, and it will usually be the one they already trusted.
This is the one most adoption plans skip. If it remains possible to brief by email, approve in a chat thread or store the final file on a shared drive, some proportion of the team will keep doing exactly that — particularly under deadline pressure, when people revert to whatever is fastest.
Adoption is not only about making the new path attractive. It is about closing the old one.
Marketing has high staff movement, and platform knowledge tends to sit with a small number of people. When they leave, the configuration they built stays behind but the reasoning does not. New starters inherit a system nobody can fully explain, and use the fraction they were shown.
In larger organisations, different teams buy independently for individual projects. The result is several subscriptions to similar products, capability nobody knows they already have, and no consolidated view of anything.
Worth separating the two problems here. Consolidation asks whether you have the right number and combination of tools; adoption asks whether the ones you keep are embedded in daily work. Removing duplicate software will not improve anything if the surviving platform is still optional. We have written separately about how to consolidate marketing project tools.
Map how work actually moves through your team before configuring anything — how requests arrive, who does what, where approvals happen, where things currently stall.
Configure the platform to that, then improve it. Teams that configure to the vendor's default and expect people to adapt get lower adoption than teams that start from their own process, even when the default is objectively better.
Include the people doing daily work in evaluation and configuration, not only the managers signing the contract. They know where the friction is, and they will spot a workflow that looks sensible in a demo and fails in practice.
It also changes the politics. A team that contributed to the decision is more likely to defend the platform and help improve it. A team that had one imposed on them is more likely to wait for it to fail.
Start with one team or one type of work. Let them use it properly, adjust the configuration based on what they find, then extend.
Two things follow. The configuration improves before it reaches everyone. And each new group joins a system that already has people who can help them, rather than everyone learning simultaneously with nobody to ask.
Train by role rather than covering the whole platform. A reviewer who approves four assets a month does not need the same session as a project manager who lives in it.
Then run refreshers a month or two in, once people have real questions. That second session is usually where the useful capability gets discovered, and it is the one most implementations skip.
Most teams have a few people who are quicker to explore a new system on their own. Give them early access and some time, and they tend to become the person others ask — faster and less formal than routing every question to whoever ran the rollout.
You do not need to ban email or chat. What you need is a clear position on where the official record lives: which system holds the brief, the current status, the approval decision and the final asset. Discussion can happen anywhere. Those four things should only be in one place.
Then be consistent about it, including with senior people — the exceptions are what tell everyone else the rule is optional.
Most organisations avoid this step because it feels heavy-handed. Consistent governance is usually what turns occasional use into an established way of working.
Implementation projects end. The platform does not.
Name someone accountable for it once the project closes — configuration changes, new starter onboarding, the relationship with the vendor. Without that, the system slowly drifts out of step with how the team works, and within a year the workarounds are back.
Active user counts are the least useful number available. Someone can log in daily and still approve in email.
What tells you something:
There is no universal adoption rate that proves success. The meaningful target depends on what has to go through the system — if every regulated approval must be documented, the target for approvals recorded in the platform is close to all of them. Feature use only matters for the capabilities relevant to each role.
Review this in the first few months. Low adoption at week six is a conversation; a year of workarounds is a project. And talk to people alongside the data — usage figures show where adoption is low and almost never why.
If you are reading this about a platform you already own and nobody uses, the first question is why — not whether to replace it.
Work through:
Talk to the people avoiding it as well as the people using it. Avoidance is usually rational — there is a step that takes longer, a field that does not fit, or a report they cannot get out.
The fix is often a configuration change, a simplified workflow, an integration, role-specific training or clearer ownership rather than a new platform. Replacement is justified when the system genuinely cannot support the process without sustained workarounds — and that is worth establishing before another procurement cycle rather than after.
Practically, a platform has landed when:
That last one is the most useful signal. A shadow spreadsheet is usually a sign that the system is not answering a question someone needs answered — worth finding out which question before assuming the person is being difficult.
Simple Admation implementations follow the pattern above: configuration mapped to how your team works, a pilot team first, role-specific training, and a named owner on your side with clear handover once the platform is live.
Because briefing, project management, proofing and approvals sit in one platform, there are fewer places for work to leak out to — and the audit trail makes it visible when it does.
You can see the staged approach in practice in our a2 Milk Company case study, where a pilot department went first, users were trained only on the parts relevant to them, and platform administration was formally handed over to named people at the end.
Usually for reasons unrelated to the software itself. The tool was bought without a clear statement of what it should improve, so using it stays optional. Training happened once at launch and never returned, leaving people with the basics and none of the capability that justified the purchase. The old way of working remained available, so under deadline pressure people reverted to it. And once the implementation project closed, nobody owned the platform, so it slowly drifted out of step with how the team actually works.
Map how work moves through your team before configuring anything — how requests arrive, who does what, where approvals happen and where work currently stalls. Configure the platform to that process rather than to the vendor default. Involve the people who will use it daily in that configuration, not only the managers approving the purchase. Then start with one team or one type of work as a pilot, adjust based on what they find, and extend from there rather than switching everyone on at once.
Train by role rather than covering everything, and run a refresher a month or two in once people have real questions — that second session is where the useful capability tends to get discovered. Give early access to the two or three people who explore new systems naturally, so others have someone to ask. Close the workarounds so briefs and approvals cannot bypass the system, applying that consistently including to senior stakeholders. And name someone accountable for the platform after the implementation project ends.
Implementation is configuring, integrating and launching the platform. Adoption is people consistently using it for the work it was brought in to manage. The two are frequently confused because implementation has a visible end date and adoption does not — a project can finish on time and on budget while the team continues working around the system. Go-live marks the start of adoption rather than the end of the project, which is why platform ownership needs to continue after the implementation team has moved on.
Active user counts are the least useful measure, because someone can log in daily and still approve in email. Better indicators are the proportion of relevant projects created in the platform, briefs submitted through the required process and approval decisions recorded in it, broken down by role rather than viewed as a single figure. Pair those with operational measures such as approval turnaround and rework, which show whether adoption is producing anything. There is no universal adoption rate that proves success — the target depends on how much of the work genuinely has to go through the system.