0

I have recently been put on a customer migration project, making customers change web/app/retail experience. The company I work for has acquired another company in the same industry.

Everywhere I have seen this done before, the explanation to the customer is company 'x' has merged with company 'y'... creating company 'z'.

My company has re-skinned/rebranded the acquired company with the same brand and colour palette. The UX/UI are slightly different. We currently have two company x's on the App Store.

My company is now explaining to the customer. Hey, company 'x' has acquired company 'y' and made it company 'x.1', and now we need you to move from company 'x.1' to company 'x'.

I'm confused writing this, so the customer must be lost! The user fear will be around migrating money in wallets, accounts, passwords, transaction history, through physical and digital channels etc.

Does anyone know of this being done before? Or any UX customer migration advice/case studies or words of wisdom.

Thanks in advance for your help \o/

  • Here's a Google translated information page from a bank in Norway doing just this: translate.google.com/… Googles translations isn't perfect and the questions doesn't seem to expand, but I bet you can figure out a way to work around it. They also sent out information to all customers and kept current conditions and terms for a while. – RolfRB May 9 at 8:50
  • Do you work at Skype? – cloudworks May 15 at 0:21
0

The problem with the scenario you describe appears to stem from renaming product Y to X.1. Now customers are confused about the difference between X and X.1. Which is "better"? Which one should new customers use? Do current users of X need to switch to X.1 (it's "newer")? Users of Y might think there's no reason to bother with X.1 because it's a different product by a different company. Etc.

To avoid confusion, product Y naming should have been retained. Instead of renaming it "X.1", it should have been called "product Y (v2) by company X". Development over several versions could converge with X, so that the backend is shared/migrated gradually over time. When it is finally time to discontinue Y and fully migrate everyone to X, users of Y will be familiar with X because of the "by company X" branding.


From a customer perspective, when company X takes over company Y, options include:

  • Stick with product Y, and its direct successors, for as long as possible, even when it is no longer supported and full of security holes. This is kind of what happened with Windows XP. People were okay with all the XP variations, but Vista was too much like an entirely different product that many refused to "upgrade". (Then MS went and repeated the scenario with Win 8 and Win 10.) I know people who are still using long-discontinued products.

  • Migrate to a different product. As support for product Y is dropped and it becomes obsolete, customers often eventually switch. Company X hopes that customers will switch to product X, but my personal inclination has been to switch to product Z.

Reasons I tend to switch from Y to Z instead of Y to X:

  • There was a reason I chose Y over X. That reason didn't go away when X acquired Y.

  • There may be reasons I prefer not to interact with company X, such as poor tech support or particularly buggy software.

  • Dropping support for product Y caused dissatisfaction and distrust.

What might company X do to encourage migration from Y to X?

  • Honor existing obligations to product Y. The more familiar people become with company X, the more likely they are to stick with it. For instance, if Y was scheduled for 5 more years of support, support it for at least 5 more years. To avoid confusion, such as what you describe, product Y naming should be retained. Instead of "X.1", it should be called "product Y (v2) by company X".

  • Develop products X and Y convergently so that they eventually share the same features and backend. Change the interfaces so that they gradually resemble each other with each successive revision. When they are essentially the same product with two different names, migrate all customers to a new unified product (so that it does not appear that users of X are being favored over users of Y).

  • Ensure feature parity between the products. Make sure the reason people initially chose Y over X is covered by X. If X lacks any essential features, there is no way for customers who need them to migrate to X.

  • Actively support migration. If the customer is left to perform the migration on their own, they are likely to attempt to switch to another product Z, especially if company Z offers to actively assist migration efforts.

Doing all of the above is very resource intensive, and few companies seem to be able to do it well. Other options include:

  • Develop products X and Y in parallel so that they remain separate products with similar features indefinitely. Do not attempt to force migration from one to the other.

  • Develop products X and Y divergently so that products fill different market niches.

  • Discontinue product Y. Integrate desired technologies into product X. Make no effort to "retain" customers.

0

Thanks for your response Xiota. My headspace has been where you are at with your advice...

Sadly the rebrand has already been made before my time, and reasons for the change/migration, is and isn't a technology solution. From a corporate perspective they sold $xm in marketing synergies to the shareholders, yet have kept quiet on the $xm in technology migration and lost $xm in customer retention. The company is an old school company in an old school industry (heavily regulated - meaning the cycle to get solution go ahead is laborious), and are quite digitally immature.

Meaning, it is not a software company doing versions etc. But a decommission of, and merger of back-end technology stacks. The option I have been given is your final point/option.

i.e. Design me an experience in discontinuing product Y that has been rebranded already as product X. Migrate customers from product Y(X.1) to product X. (Incentives include here is some money $20-100 to merge accounts.)

From a customer experience perspective, and design perspective, I do not agree with this.

  • Is it possible... instead of forcing X.1 to X, make X.2 as an intermediary. Then make X.3 as a final product to which users of both X and X.2 would be migrated... ? If you're stuck forcing X.1 to switch to X, I'd expect lots of lost customers. If that's acceptable to management, then it is what it is. I suppose there's also the whistle-blower approach to get stockholders to vote on changing management. Just depends on how much you really care about the issue and how much punishment you're willing to take for it. – 習約塔 May 13 at 5:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.