Japanese Enterprises Do Not Start Free Trials.
They Ask You to Run a PoC.

▶ 60-Second Slide Summary Prefer the 8-slide version of this article? Tap to read in 60 seconds. View slides →

Quick Answers

Why does the enterprise account never touch our free trial?

Because a trial gives them nothing to hand upward. It is designed for one person to decide, privately, whether the product works, and in an enterprise that private conclusion is not the thing standing between you and a contract. A PoC produces a written report with a period, named participants and agreed evaluation items — the artefact the internal approval request needs as an attachment. Your trial and their PoC are aimed at different readers.

So a PoC is a trial with more support?

Not in the way it is governed. The centre of a PoC is the list of evaluation items agreed before it starts, because that list determines what the final report is able to say. It is normally drafted by the information systems department and the user team who raised the request, working from measures they already know how to defend internally. If you have not seen it before the PoC begins, your product is being scored on axes chosen without you.

TL;DR

Your Japanese trial page is live, the signup flow works, and the enterprise logos in your pipeline never use it. What arrives instead, usually after the third meeting, is a question about whether you could start with a 実証実験 — a proof of concept. Reading that as a longer trial with more hand-holding is what costs the next four months. A trial lets a buyer decide for themselves. A PoC produces a document that someone has to defend in front of people who never opened the product, and it comes with a period, named participants on both sides, and a list of evaluation items. Whoever drafts that list has already done most of the work of deciding what the report will conclude. If you are not in the room when it is written, it gets written by the people who will have to defend it, out of the measures they already know how to defend.

Key Takeaways

• A trial is self-service. A PoC is a governed project. Fixed period, named participants, agreed evaluation items, and a report at the end that goes to people who were never in the room.
• The evaluation criteria are the negotiation. Drafted by the customer alone, they use measures the customer already knows how to defend — and what makes you better than the incumbent may not appear as a row at all.
• The report is the deliverable. "It worked" is not a result. Numbers against each agreed item, plus written notes on conditions and limits, in Japanese, because it circulates.
• Free has a price. Six unpaid weeks of configuration, training and a written report establish what those things are worth, and the renewal conversation starts from there.
• Bring a draft to the first PoC conversation. Criteria, period, end condition, and who writes what on the final day.

The Trial Link Nobody in That Account Ever Clicks

The Japanese trial page has been live for four months. The signup flow works, the onboarding emails go out in Japanese, and the docs were reviewed properly rather than pushed through a machine. Mid-market accounts do use it. Individual engineers use it. The three enterprise names your board asks about every quarter have never started one.

What arrives instead is a message from your champion, usually after the third meeting. It is polite and slightly indirect, and the operative phrase is 実証実験 — a proof of concept. Could you start with one, on a limited scope, with one department? They can introduce the team.

Headquarters reads that as interest plus procedural friction, and answers accordingly: a trial account can be issued this afternoon, free, for as long as they need, with a solutions engineer on call. The reply is generous. It also does not move anything, and two weeks later the same question comes back slightly rephrased.

The scene above is a composite drawn from a pattern I see repeatedly in Japan-entry work. It is not a description of a specific client or customer.

A Trial Asks Whether the Product Works. A PoC Asks Whether Someone Can Say So.

A self-serve trial is built around a single person forming a private opinion. They sign up, push the product around for a week, and decide. Nothing they conclude has to be written down, and nothing has to survive being read by anyone who was not there. In markets where a department head can sign, that is enough, and the trial is the whole evaluation.

The PoC your champion is asking for is aimed at a different reader. They are not the person who signs. Whatever they conclude has to travel — to their manager, to the information systems department, often to finance, sometimes to a risk or internal audit function. None of those people will open your product. They will read a document about it, months after the fact, alongside four other requests competing for the same approval.

So the question quietly changes shape. It stops being does this work and becomes can what happened be written down in a form that holds up while it circulates. That is not scepticism about your product. It is the same structure that shows up everywhere else in a Japanese purchase: the person in front of you is assembling something they will have to defend in a room you are not in, which is also why the real meeting often happens before the meeting.

Whoever Drafts the Evaluation Criteria Has Already Shaped the Answer

Every PoC that gets written up has an evaluation table behind it — 評価項目 or 評価基準, depending on the company. It is usually unglamorous: a handful of rows, each with the item being checked, how it will be measured, a target, a result, and a comment column. It fits on one page. It is also, in practical terms, the entire negotiation.

Left alone, the customer will draft it. That drafting is done by the people who will have to stand behind it — the information systems department and the user team who raised the request in the first place. They are not building a case against you. They are building a document they can defend, so they write down the things they already know how to measure and already know how to justify.

Two things follow, and neither is obvious from headquarters. The first is that whatever is genuinely stronger about your product than the incumbent may not appear as a row. A capability that is not on the list cannot score, no matter how well it performs during the six weeks. The second is the reverse: rows appear that your product was never built to answer, often carried over from an evaluation of a different category of tool. A blank cell or a "not applicable" in a scoring table reads badly to someone who was not there to hear the explanation.

The correction is unspectacular. Offer a draft. Four to eight rows, in Japanese, presented as a starting point rather than a submission, with an explicit invitation to add and cut. Nobody in this situation is offended by a vendor who arrives with a proposed way of measuring things — the request is usually treated as a sign that you have done this before.

The Deliverable Is the Report

A PoC in a Japanese enterprise arrives with three attachments to it, and the third is the one foreign vendors underestimate.

A period. It has a start and an end, and the end is rarely chosen for technical reasons. It is chosen so the write-up lands before an internal approval window — which, in most Japanese companies, is anchored to a fiscal year that does not line up with your own. A PoC that runs two weeks long can miss the cycle it was meant to feed by an entire quarter.

A team. Named people on both sides. The Japanese side will want to know who from your company is participating, in what capacity, and in which time zone. "Our solutions engineering team is available" answers none of that. A name and a working-hours commitment answers all of it.

A report. This is the point of the exercise. Your champion attaches it to the internal request, and from that moment the report is the product as far as the organisation is concerned. "The team found it useful" is not a result. What is needed is the agreed evaluation table with a measured value in each row, plus written observations about the conditions the numbers were produced under and where the limits were. The document has to be readable cold, six weeks later, by someone in finance who has no context and no reason to be generous.

It also has to be in Japanese, for exactly the reason the security questionnaire has to be: it circulates among people who were not part of the evaluation. If you do not produce the Japanese version, your champion writes it in the evening, and then they are the one vouching internally for a set of numbers they did not generate.

Japan Already Has Contract Language for Work With an Uncertain Outcome

It helps to know that none of this is being improvised at your expense. There is an established domestic vocabulary for engagements whose result cannot be specified in advance, and it is published by a government-affiliated body.

IPA, the Information-technology Promotion Agency, maintains model contracts for information system transactions between customers and vendors. The stated intent of the second edition is that both sides use it to reach a shared understanding, at the point of contracting, of the specification, how the project will be managed, and how acceptance will be judged. Acceptance criteria settled before the work begins is the default assumption here, not an unusual request.

For work that genuinely cannot be specified up front, IPA published an agile-development version of the model contract on 31 March 2020. It is built on a 準委任契約, a quasi-mandate contract, in which the customer pays for the vendor to carry out the work as a professional rather than for the completion of a pre-specified deliverable. It also ships with a pre-contract checklist covering whether the purpose and goals of the project are clear to both sides before anyone signs anything.

Two things are worth taking from that. Exploratory work with an unguaranteed outcome is normally a paid engagement in the domestic reference model. And agreeing in writing, before starting, what the work is for and how it will be judged is the expected shape rather than an imposition. When you arrive with a criteria draft and a proposed end condition, you are not being pushy. You are behaving like a vendor who has read the local playbook.

The Unpaid PoC That Does Not End

Free is the natural instinct, and the reasoning is sound on its own terms. It is still a sales cycle, the product is already built, and the engineering time is a rounding error against the contract value. Nobody wants to introduce a commercial conversation into a stage that feels like goodwill.

Two things happen when an unpaid PoC runs long. The first is that its internal weight stays low. Nothing had to be approved, so nobody had to name it in a budget line or attach their signature to a decision about it. It sits in the same category as the other exploratory things people are doing, which means it survives on the enthusiasm of one champion and stops when that champion is moved.

The second is that a price gets set without anyone naming one. Six weeks of configuration, three training sessions and a written Japanese report, all delivered at no charge, establish what those things are worth. The professional services line in the eventual quote starts from that number, and so does the renewal conversation a year later, when the same support is expected and is no longer free.

A paid PoC changes what has to happen internally: money has to be approved, an approver gets involved, and the project becomes visible at a level above your champion. Whether that helps depends on the account. There are companies where a modest fee is easier to approve than an unpaid commitment of staff time, and companies where introducing a charge at this stage ends the conversation. The useful move is to stop treating free as the default and decide it deliberately, per account.

Either way, the end condition matters more than the price. What happens on the final day, who writes the report, and what decision is expected once it exists — agreed in writing, before the first configuration call.

What to Put on the Table in the First PoC Conversation

1. A draft of the evaluation items, in Japanese. Four to eight rows: what is being checked, how it will be measured, what counts as a result, and who supplies the data. Present it as a draft and ask what to add. The customer will edit it, and that editing session is the most useful hour of the entire PoC.
2. A stated end date, with a written exit condition. Not "we will see how it goes". What is delivered on the last day, by whom, and what decision follows. This is the single item that separates a PoC from an indefinite free deployment.
3. Named participants and working hours on both sides. Who answers a question at ten in the morning Tokyo time, and what happens to a question raised at four in the afternoon.
4. A Japanese report template, prepared before the PoC starts. Written in advance, it forces you to notice which numbers you will need and cannot currently produce. Written afterwards, it becomes a scramble. Built once, it is reusable: the second customer's PoC fills in the same structure, and the third is an editing job.
5. A written note of what is out of scope. Custom integrations, data migration, on-site training. Decided in week zero rather than negotiated in week four, when saying no starts to look like a change of position.

None of this requires headcount you do not have. It requires treating the PoC as a documentation project with a product attached, and keeping the artefacts as company assets rather than as files in one salesperson's folder.

What the Request Is Actually Telling You

When a champion asks for a PoC instead of taking the trial you offered, they have often already decided they want the product. The PoC is not them checking whether it works. It is them beginning to assemble the case they will have to make on your behalf, in a language and a format you will never see unless you ask.

Which makes the request more useful than it looks. You are being given early sight of the argument before it is scored — the criteria, the timeline, the internal readers. That access does not exist in markets where a buyer simply decides, and most foreign vendors spend it arguing that a trial would be faster.

If your Japan pipeline has opportunities parked in a stage called PoC, the thing to check is not the product usage numbers. It is whether anyone on your side has seen the evaluation table, and whether a date exists on which someone has agreed to write something down. If the answer to both is no, the PoC is not running. It is just open.

A Japan Readiness Check reads your Japanese-facing material the way an internal reviewer reads it, and shows where a customer's own evaluation and approval process runs out of things it can cite.

Frequently Asked Questions