Common XPLAN implementation mistakes (and how to avoid them)
Most XPLAN implementations don't fail loudly. Nobody gets an error message that says "this was a bad idea." Instead, the site gets built, everyone moves on to producing advice, and eighteen months later a new hire asks why a particular workflow works the way it does and nobody has an answer.
We've implemented and rescued a lot of XPLAN sites over the years. The mistakes are rarely dramatic. They're small decisions made under time pressure that quietly compound.
Starting from a blank site instead of a proven framework
The instinct is to start clean and configure as you go, template by template, as each need comes up. It feels flexible. In practice it means every template is a one-off decision, made by whoever was under the most deadline pressure that week, with no shared logic tying them together.
A framework that already works, tuned to your advice style, avoids this by design: the templates, fact finders and reports arrive with a consistent structure, and customisation happens on top of that structure instead of inventing it from scratch.
Migrating data before deciding what "clean" looks like
Migration is the one moment data quality either gets fixed or gets permanently inherited. The common mistake is moving everything as-is with a plan to "clean it up later." Later rarely comes, because by the time anyone notices, the messy data is already load-bearing.
Decide what a complete, trusted client record looks like for your practice before migration starts, migrate to that standard, and set up feed health checks from day one rather than discovering in month four that a platform balance stopped updating in month two.
Treating training as a one-hour handover
A common pattern: the implementation finishes, someone runs a single walkthrough session, and the team is left to work out the rest by clicking around. Six months later, half the practice is using workarounds for things the system already does properly, because nobody had time to learn the real workflow.
Proper training run on the actual site, not a demo environment, is cheap compared to the compounding cost of a team that never learned what they were given.
No single owner for the site after go-live
Implementation projects usually have a clear owner. Once the site is live, that ownership often quietly evaporates: everyone's a little bit responsible, which in practice means nobody is. Templates drift out of sync with regulation, small breakages get worked around instead of fixed, and eventually the informal fixes become the process.
Decide, in writing, who owns the site after go-live: in-house, outsourced, or a defined mix, before the implementation team walks away.
Configuring for the demo, not the busy season
It's easy to configure and test a workflow when there's one client file open and plenty of time. The real test is whether it holds up during a busy compliance period with twenty advisers working simultaneously. Implementations that only get tested lightly tend to reveal their weak points at the worst possible time.
Test against realistic volume and realistic edge cases before go-live, not just the happy path.
The pattern behind all five
Every one of these mistakes has the same shape: a reasonable-sounding shortcut under time pressure, that quietly becomes permanent. None of them are things anyone chooses on purpose. They're what happens by default when nobody's specifically watching for them.
If you're planning an XPLAN implementation and want a second opinion on the approach, a free Advice Tech Health Check is thirty minutes with a senior consultant, no obligation either way.