Consilegy MEDIA

Change management

When your Japan team asks to go back to the spreadsheet, answer with a date

When your Japan team asks to go back to the spreadsheet, answer with a date

About a month after the global CRM goes live in Japan, someone asks to go back to the old spreadsheet.

The request rarely arrives as a demand. It comes softened, often through the local manager rather than in the review call, phrased as something that might be a little difficult for the team. HQ files it under settling-in and answers that everyone needs more time with the new system.

That answer is not wrong. It is just answering a different question than the one being asked.

The Japan team is the only group that has run the same work through both systems

Plenty of people can critique the design. Almost nobody has used both.

The HQ team saw the legacy spreadsheet once, during requirements gathering, translated. The regional sponsor approved a slide, not a screen. The only people who have closed the same deal twice, once the old way and once the new way, sit in the Japan office.

So the request is not resistance. It is the only comparative report HQ is going to get, and it arrives disguised as a complaint.

It also has a shelf life. Raised twice with no visible result, it stops being raised. In a Japanese office that threshold is lower than HQ expects, because raising it a third time starts to look like a personal position against a decision that has already been approved.

Mazrica’s survey on SFA and CRM usage (fielded by IDEATECH, 25 to 28 November 2024, published 28 January 2025, n=101 sales managers and team leads at Japanese B2B companies; run by a company that sells sales software, on a small sample, so read it directionally) found the top usage complaints were that entering and updating information is cumbersome, 43.6%, and that the system is hard to operate, 38.6%. Neither of those is visible from a design review. Both are only visible from use.

Answering yes or no moves the request out of your reporting, not out of the business

In practice HQ picks one of two answers. No, the global design stands. Or yes, we will allow a local exception.

What happens next is the same either way. The person who asked works out how to do their job regardless. The global CRM gets whatever the weekly pipeline call requires. The information they actually work from lives in a file on their machine.

Adoption metrics hold up. The data stops describing the business.

And from that point, design gaps stop getting reported at all. Someone with a workaround is no longer blocked, so they have nothing to raise.

No Japanese public survey measures how often a parallel file exists, at least none I have been able to find. The closest is Keywalker’s survey (fielded 8 to 10 October 2025, published 11 November 2025, n=1,034 sales staff and managers at Japanese companies already using SFA, CRM or BI tools, run online through PRIZMA; a survey by a company that sells BI implementation services), where 12.5% of respondents said they are not entering data or have frequent gaps. That measures admitted non-entry, not where the data went instead.

Since it cannot be measured from HQ, it has to be spotted. A file you do not recognise flashes past during a screen share. You ask about a deal and hear context that is nowhere in the record. Every Japan opportunity has a last-modified timestamp from the day before the regional call.

The team does not want the old system back, it wants one thing the old system did

Nobody in Japan is nostalgic about the legacy spreadsheet. The request points at one job the old way did that the new design has not picked up. Usually one of three.

  • Speed. Ten seconds in the spreadsheet becomes open the CRM, find the account, find the deal, pick from a dropdown. In the same Keywalker survey, 30.7% of those whose entry is delayed cited difficulty entering data on mobile. Japanese B2B sales involves a great deal of travel between client sites, so entry that used to happen on a train now happens at 9pm, or not at all
  • Somewhere to put information that is not confirmed yet. This is the one HQ almost never sees. The local spreadsheet held things that were not ready to be seen: a read on how the meeting went, which internal stakeholder is actually blocking, what needs checking before the next visit. A global CRM designed to hold confirmed facts only leaves that material with nowhere to go, and in a culture where putting an unconfirmed judgement into a system of record visible to HQ carries real personal cost, it goes back to the private file immediately
  • Seeing everything at once. The old sheet showed all accounts on one screen. Most CRM layouts show one record at a time. Anyone whose working habit starts with a morning scan of the whole book of business loses that habit on day one

Speed and the overview are usually configuration problems. The middle one is not. It cannot be fixed by adding a field, because the issue is not the absence of a place to type. It is who can read what gets typed.

An exception you can count is cheaper than a file you cannot see

The answer to give is not yes or no. It is a date.

Tell the Japan team you will come back within two weeks with a decision on where that one job now lives. Then decide, before the two weeks start, what happens if the answer is that it does not live anywhere yet.

If it does not, keep the old way for that one thing, and keep it in the open. Name it as an exception, write down when it gets reviewed, and make it something you can count users of.

To the Japan team, an official exception and a private file feel identical. To whoever owns the platform, they are opposites. An exception appears in a review and eventually closes. A private file has no owner, no review, and no closing date.

Documented exceptions also give you a priority list that no survey will. If three people in the Japan entity are using the same exception, that is not a local preference. That is a gap in the global design that Japan happened to find first, and the other regions are working around it silently.

A request to go back names one job the old way did that the new design has not picked up. Answer it with yes or no and the request does not disappear. It moves to a file you cannot see, and it stops being reported.

Common mistakes

  • Treating it as a familiarity problem. Speed and the overview do resolve with a few weeks of use. Somewhere to put unconfirmed information does not. Reaching for the familiarity answer before asking which of the three it is guarantees you never hear the fourth request
  • Removing the fallback instead of replacing it. Revoking access to the legacy system, disabling exports. What this produces is not new CRM entries. It produces handwritten notes. Taking away the place without providing a place only removes the information
  • Assuming one exception means everyone reverts. Very few people actually want to go back. Driving exceptions to zero out of that fear does not reduce the number of workarounds, it only reduces the number you know about. Manage exceptions by whether they are countable, not by how few of them there are

The decision about when the legacy system stops running at all comes before any of this. Setting that on an exit condition rather than a date is covered in Japan’s parallel run has an end date but no end condition.

Other notes on the same problem are collected under Change management.