Behind every software release lie legion opportunities to ruin your customer relationships
Happy New Year!
It’s often a challenge to get it right when it comes to upgrading your technology and, in the world of insurance platforms, 2024 is likely to be a year full of upgrades.
So, here’s our 10-point guide to keeping your customers and users happy when upgrading your technology. Each and every one of these, by the way, has been learned the hard way!
- Don’t throw the baby out with the bathwater.
If your customers have been using your kit for any longer than a year or two, they will be used to its foibles, understand its terminology and know its workflow blindfold. It will be embedded into their daily routine, their subconscious and muscle memory. It might even be integrated into their other systems with APIs or other less convenient means.
Mess with all that at your peril.
The purpose of an upgrade is to improve it, not change everything just because you want it to look more modern or different. That’s a sure-fire way to alienate your users and put the helpdesk under stress. And it will probably lose you customers unless you’re lucky enough to run a monopoly service for users who have no other choice. But, even then, don’t pretend they’ll forgive you. They won’t.
- Resist the temptation of shiny.
Remember that business software is not quite the same as consumer software, so don’t think your users will be lured by shiny baubles, especially if the system is functionally inadequate in areas of importance to them. Although consumer portals need to look sharp, modern and slick with all the new bells and whistles, business portals do not quite so much – they need to be user-friendly, efficient, reliable and above all else, do what they say on the tin.
Efficiency should trump shiny every time so don’t go messing with your users’ lives just because you think they want gloss. Matt, satin and eggshell are all perfectly acceptable to paint a well-designed and constructed side table.
And you don’t need to be a UX expert to spot an inefficient workflow – you just need to be honest with yourself. Is this quick and easy to use? No? So fix it before you release it.
- Never deprecate anything.
Okay, let’s qualify that a bit with: unless it’s absolutely proven to be redundant, never used or completely unsupportable. But do you really know how people use your software? Are you sure? If you’ve got, say, 10,000 users, do you know how each of them uses it every day? Of course you don’t. Nor does the user group. So before you deprecate a function, have the devs put a monitor on it and see how often it gets clicked. Or maybe you prefer irate users and reputational damage after your release goes live? It’s your call.
- Train your helpdesk first.
The first people to be trained on any upgrade must be your helpdesk team – they must know it inside out before you attempt a live release with real users. No matter how good your upgrade is, some users will still need help, especially if you’ve got some unexpected “features” still lurking in the code, and your frontline troops in customer support will be the first to get hit by the fallout.
They’re your greatest brand ambassadors and every interaction they have with your clients is your opportunity to show them that you’re the best. And that you care. Most of your users will only ever know your company through the helpdesk and if they can’t respond with assistance, quickly, professionally and effectively, you’re in for real trouble. Your reputation is on the line and your failure to train your ambassadors is destroying it call by call.
And if you’ve got a major upgrade going out and you know you’re likely to get a lot more calls from confused users than normal, then bolster the helpdesk team with some contractors and train them before you release. It’ll cost a bit but will pay dividends.
- Listen to your customers but don’t be led by them.
You’re a technology company; you provide interesting, exciting and useful technological solutions to your customers’ problems. Your user group is obviously essential for interaction, feedback and negotiation but if they knew exactly what they wanted and how to solve every issue themselves, you’d be out of a job. But they don’t. And users will often ask for one thing but what they really mean is something slightly different. So always listen with intent but act on their requests with careful consideration – a task you can only perform properly if you absolutely understand their job and how they do it.
And your mission with every new release must be to provide them with functionality they didn’t even know they needed. That’s how real progress is made. Every upgrade should include a pleasant and unexpected surprise – and benefits – for your users.
- Be wary of stakeholder overinfluence.
If you’re fortunate enough to have shareholders vested in the business with no other agenda, you can happily skip this one, as you’re all on the same side. But if your stakeholder community runs deep into your clientbase and they effectively dictate your strategy and your roadmap, you’ll be spending most of your life herding cats. Trying to please everyone pleases no-one.
If their demands for your upgrade schedule do not coincide with what your project management can achieve for technological, budgetary or logistical reasons but you can’t say no, a recipe for disaster is in the making.
Technology companies have a mission. Stick to it like glue and give siren voices and aggressive stakeholders a wide berth – their mission is not the same as yours.
- Learn how to say no.
Everybody wants everything so nobody gets anything unless you have infinite resources, which I’m prepared to bet you don’t. So, when you’re asked to provide something in the next release, ask yourself if it fits your strategy. Does it take your software in the direction you want? If it does, thank them profusely for their input. If it doesn’t, just say no.
Practice saying no in the mirror each morning – you’ll soon get the hang of it, and you’ll never again rue the day you committed to something that will drag you in the wrong direction, or worse, down.
- Test, test and retest.
It sounds obvious but releasing inadequately tested software is something you really should avoid doing. And testing is not just about using a professional tester with a scripting tool either. It’s about getting people like me to try to break it. People like me are people like your users – unpredictable, sometimes lost, often confused, never taking the “happy path” with a nasty habit of going way off-piste. And we have a phobia of reading manuals and help text.
We use your software in ways you didn’t necessarily foresee and we can break it really easily by doing things you never thought anyone would try.
You may think we’re morons, but we are in fact your greatest asset.
People like us should never be “testing” your software after its live release but should have been asked to help test it in a pre-release sandbox first. You have a user group – so ask them to field some guinea pigs. Many will happily oblige, if only to reduce the risk of chaos when it all goes live. Chaos that will cost them time and money; and you your reputation.
- Release small and often.
Take a leaf out of Google’s book. Or Intuit’s. Or NatWest Online, or any of the other major platforms out there. They are almost constantly changing, often imperceptibly. Not for them big bangs with resounding echoes. Their releases often go unannounced and new functions pop up with a little on-screen “try me” prompt, users give them a go and continue to use them if they’re happy. Or they vent their rage on “X” if not.
Of course, B2B software needs to be controlled but not necessarily as much as we used to believe, and it should not be materially different in intent – release small, release often. Keep user’s learning curves short and low.
And at all costs, keep them happy, informed and engaged.
- Schedule releases with consideration.
If you’re in insurance, and your release is a bigger one, think carefully about when your users will be most happy to be diverted from their workload to get to grips with new functionality and change. London has clear renewal season patterns, with years of trading history to gather stats from, so there’s really no need to be releasing major upgrades over frantic renewal seasons.
Give your users consideration, show them you care, and they will return the favour in kind and support you when the going gets tough which, occasionally, it will no matter how hard you try.
We try hard to follow these mantras at Ebix Europe but, like all fallible humans, we occasionally get it wrong but are most fortunate to have very solid support from our clients who have been most forgiving of our occasional transgressions!
Which brings me to one final, bonus point.
- Don’t make excuses for your own failings.
If your upgrade is a big one and you’ve neglected some of the more important points above, don’t try to justify the havoc you’ve wreaked among your users with the old “people just don’t like change” excuse. Of course they don’t, and neither do you if it’s not absolutely necessary. Microsoft Word still looks recognisable after four decades for good reason. As do Excel, Amazon, Google, MacOs and most of the other apps and platforms you’ve grown to depend on.
Everyone will welcome change if it makes their lives better. Nobody will thank you for making it worse with an ill-considered upgrade, even temporarily.
James Pring
Ebix Europe