In March I began the mammoth task of transitioning ~1,400 customers over to my new platform. I've written about:
I now have 6 months under my belt. I'm half way through the rebuild and pretty burnt out. It's ironic that the end goal is to automate the business yet I've created more work for myself!
On more than one occasion I've had to remind myself that this part of the rebuild involves short-term stress for long-term freedom. With 82% of my customers completing the migration process the hands-on effort is clearly worth it, even if it has created more work for me.
Overall the experience has been mostly positive. It's definitely going better than I expected, but that doesn't mean it's without friction. Now that I have 6 months and hundreds of migrations behind me, let's look at the consistent frictions I've encountered and what I can do to iron them out for the second half.
Learned behaviour is difficult to disrupt
I knew learned behaviour would be difficult to change after almost a decade of building a business that relied so heavily on me. It came up in focus groups too. Customers value the human touch and worry about getting something wrong if left to their own devices.
The migration has shown that lots of customers still want me to do things for them.
"Can you email me my receipts?" They're in your dashboard.
"Can you tell me how much it will cost to add this?" Your dashboard will tell you.
"Can you send me my policy documents?" They're in your dashboard.
"Can you cancel my policy?" You can do this from your dashboard.
There are always going to be cases where I need to get involved for accessibility, usability or other reasons. But most of the time this is learned behaviour. No matter how easy we've made these tasks, the default for many is still "I'll just ask Ashley."
I've created that behaviour by spending a decade building my business around being available to customers whenever they need me. I can't expect that behaviour to disappear overnight just because I've built a dashboard.
But I have a baby due in a few months. Being available 24/7 needs to change, especially when the tools are now available for customers to manage their policy themselves.
Reducing my admin was one of the reasons I invested so heavily in this software. Breaking this habit before my baby arrives is important for my work/life balance, but also for my customers. I won't always be as available as I have been, so they need to feel confident getting what they need without relying on me.
I have a tech-savvy customer base. Many of my customers are designers and developers who have worked on systems like these. I know my customers are capable with self-service and that isn't really a technology problem. It's a behaviour problem.
They know how to use the tools, but after 10 years of dealing directly with a human, their instinct is still to ask first.
Solution? Gently and consistently redirect people to the tools I've built for them. It's in your dashboard. You can do this yourself. Here's where you'll find it.
Supporting two customer journeys creates temporary friction
The new platform has to accommodate two different types of customer. We have new customers buying a policy for the first time, and existing customers migrating from the old system.
The platform is optimised for new customers because the migration is temporary. It's a one-and-done process. Because of this it doesn't make sense to design a permanent flow around the migration.
However, that has created some awkward edge cases.
One of the common edge cases is existing customers assuming that they already have an account on the new platform.
"I've tried logging in and get an error. The reset password link isn't working."
We do explain account creation across the renewal emails, demo and migration guide (and ensure it's the only system-related call-to-action!) but I still have to provide additional support.
Payments are another complication. Existing customers may still have instalments associated with the old system while being asked to set up a new payment method during migration. This causes confusion and in some cases duplicate payments.
These frictions come from trying to support two different customer needs across one system. A system that has, like I said, been optimised for new sign-ups.
Solution? I invested thousands on communications to make the migration process as clear as possible. We've done a good job of that. It's mostly worked, but no amount of communication will eliminate every point of confusion during a migration this size. I could build permanent functionality to address payment overlaps, but that feels wasteful because it's a temporary problem. In this instance I'm happier to accept some friction rather than over-engineer for a migration process that will soon disappear.
Customers assume their circumstances are too complicated for self-service
I've spent a decade working with freelancers. It's rare for something to arise that I haven't encountered before. In fact, I can't remember the last time that happened.
I've invested tens of thousands of pounds using everything I've learned over that decade to build this system. But some customers are still bypassing it before discovering whether it can meet their needs.
“My situation has changed. It's a little complicated now, I need to speak to a human.”
After we've spoken, the complex situation is that they now offer an additional service. Good thing we've built the system to accommodate multi-disciplinary freelancers by allowing them to select up to five services.
Or:
“Some of my clients are in America so I'm not sure whether your system can accommodate me.”
Good thing there's a checkbox to extend your coverage to include US clients.
And even:
“I have a new contract that requires a higher level of cover. Can you still accommodate me?”
Good thing there's an “Edit your policy” button with five levels of cover to choose from.
Insurance isn't something you want to get wrong so I understand why these questions are being asked. They don't know what the system can accommodate until they try it, but I've paid my dues having these conversations for 10 years. That's precisely why I knew to build for multi-disciplinary freelancers, international exposures, different cover combinations and other scenarios, too.
The customer thinks they're presenting me with unusual circumstances, but I encountered those circumstances 2,500 customers ago. I've considered it when designing the customer journey.
Solution? The system already solves the problem. The challenge is getting customers to trust that it does.
Risk questions are still the bane of my life
The risk questions are written by underwriters so they'll always sound different from the website's otherwise casual tone and copy. But that's a good thing. It signals to the customer that this is the serious part.
After 9 years of seeing which questions commonly trigger referrals, I was excited to finally have a chance to reduce these.
The biggest change was prefacing a lot of our copy with "If you do this thing..." to reduce unnecessary referrals. An example of the old question set; Please confirm you have explicit consent to collect personally identifiable information.
People were answering false despite not collecting personally identifiable information. This triggered an underwriting referral that technically didn't need reviewed because no PII was being collected. To avoid this we prefaced it with "If you collect personally identifiable information".
To my surprise people are still answering 'false' despite not doing the thing in the first place. The result is the same as before: a referral that didn't need to happen and another support query for me to deal with. It's been a useful reminder that a question that seems unambiguous to me can still be interpreted differently by a customer.
I've also lost sign-ups because of this where I haven't been quick to respond to the referral because I've been in a meeting, on a dog walk or it's the evening. By the time I reach them they say "Oh, that was a mistake. I should have answered 'true' but I've now got it sorted elsewhere".
The risk questions generate a disproportionate amount of support despite the amendments. Figuring out how to reduce these would make a huge difference to my workload.
Solution? I'm going overboard with the helper text. No matter how obvious a question seems, it's getting the 'explain it like I'm five' treatment.
I think my biggest lesson is that not all friction needs the same response. Some needs fixing. Some needs designing around. And some friction simply needs accepting.
Not every point of friction is a problem I need to solve. The priority is making the right things easy for most people, reducing the work that unnecessarily relies on me, and trusting the system I've spent years building to do its job.
Six months down. Six to go. Just as the migration comes to an end and all going well, we'll be welcoming our baby girl into the world. I couldn't have planned it better if I'd tried.
