CRM adoption
A CRM in Japan is rarely abandoned. It is filled in just enough to survive the weekly meeting, which is worse, because the reports keep rendering and nobody can tell they are wrong.
This category covers the design decisions behind that outcome: which properties earn their place, separating lifecycle from deal stage, what to clean before an import, and why adding a required field is usually the change that breaks adoption.
10 articles
Japan CRM deal amounts: why the pipeline won't reconcile
HQ rolls up the Japan pipeline and it does not match billing. The cause is rarely optimism. It is the deal amount field: Japanese reps copy numbers from quotes, invoices and approval documents that each state the price differently, and one field asks four questions at once. How to split the field, let the CRM compute ARR, and decide which system wins.
CRM migration in Japan: when they ask to move every field
Your Japan team asks to migrate every field from the legacy system and says the unused ones can be deleted later. They will not be. HubSpot's own documentation shows why: a property in use cannot be archived, and an archived property is permanently deleted after 90 days. Reframe the choice from keep-or-discard to CRM-property-or-readable-archive, and the negotiation ends.
Why your Japan workflow fired three times and nobody reported it
A global workflow sent the same notification three nights running to Japanese contacts. Re-enrollment was off. The cause was a trigger built on a property the workflow itself wrote, combined with a local nightly sync that rewrites every field. Why this pattern is close to universal in Japan subsidiaries, why the Japan team reports it as silence rather than a bug, and the one-line test to run before go-live.
In Japan, a required field produces confident wrong answers
HQ sees blank fields in the Japan pipeline and makes them required. Completion goes to 100% and the data gets worse, because in a Japanese deal the answer often does not exist yet at the moment the record is saved. Japanese survey data (n=101, n=1,034), why the economic buyer field fails specifically in Japan, and the two conditions a field must meet before you require it.
Your Japan team wants records hidden. Almost none of it is confidentiality.
When a global SaaS company rolls out its CRM in Japan, the local team asks for visibility restrictions HQ has never granted anywhere else. Most of those requests are about who owns a record, not about what is in it, and the two break in completely different ways after go-live. Japanese survey data (n=101, n=1,545) and the question to ask before you touch the permission model.
Your Japan integration will not fail on the connector. It fails on the key.
Your Japan subsidiary runs its customer master in kintone or a domestic package, and HQ mandates the global CRM. The integration stalls, and the vendor evaluation gets blamed. The real blocker is that nobody has decided which single field identifies the same customer, and which system is right for each field.
Your Japan team wants its own pipeline. Give them four fields instead.
When the Japan team asks for a separate pipeline, the real problem is usually that your global stages have no way to represent where a Japanese deal actually sits: inside an approval process that takes months. Splitting the pipeline hides that. Adding fields exposes it.
Choosing a CRM for your Japan team: three decisions that settle it
Headquarters assumes the global CRM will simply extend to Japan, and six months later the Japan team is running a spreadsheet next to it. The tool is rarely the problem. Who enters the data, which system holds the master record, and who administers it locally are the three decisions that decide whether the rollout survives.
Before importing your Japan contact lists, decide three things
When a global SaaS company stands up a CRM for its Japan team, someone always says "just import what we have." Japanese business-card and spreadsheet data breaks matching, overwrite and email-consent rules in ways HQ playbooks do not anticipate. Decide these three points before the import, not after.
Setting up HubSpot for a Japan team: don't merge lifecycle stage and deal stage
Global SaaS teams often collapse lifecycle stage and deal stage into one funnel when they stand up HubSpot for Japan. It corrupts the numbers HQ reads. Here is why the two must stay separate.
Frequently asked
- Should the Japan team use our global CRM instance?
- Yes for the object model, no for the required fields and the stage definitions. The approval chain described in the Japan market entry articles has no representation in a standard global pipeline, so Japanese deals either sit in one stage for months or get advanced on optimism. Add the local fields to the shared instance rather than forking it.
- Why do our Japanese reps not fill in the CRM?
- Because nothing comes back to the person doing the typing. A survey by Mazrica conducted in November 2024 (n=101, sales managers at B2B companies, a self-published study by an SFA vendor and a small sample) found the top reason for not entering data was that it takes too long, at 54.5%, with 32.7% saying they could not see what they gained from it. Reducing fields helps less than showing the person what the data is used for.
- How common is CRM adoption in Japan generally?
- Lower than most headquarters assume. HubSpot Japan's annual survey (2026 edition, conducted by Macromill, n=1,545 sellers at companies of 51 to 5,000 employees, a self-published study by a CRM vendor) put CRM adoption at 38.1%, roughly flat since 2022. Your Japanese prospects are often evaluating a category, not just your product.