Why a Translated Proposal
Loses a Japanese RFP

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

Quick Answers

Why does a translated English proposal score poorly in a Japanese RFP?

Japanese RFPs, particularly in the public sector, often publish the evaluation items, the points for each and the forms to answer in. Evaluators read your response against that list. A translated template follows your own structure, so the evaluator cannot easily find which part answers which requirement, and unclear answers to mandatory requirements can cost the whole bid.

What should a response to a Japanese RFP look like?

It should use the issuer's forms without changing them, follow the numbering of the evaluation criteria, answer each requirement on its own line with the support level the RFP defines and a page reference, state limitations and alternatives openly, and include a Japanese company overview, similar track record, a team chart and a quote in the specified format.

TL;DR

Do not send your global proposal in translation. Start from the issuer's forms and evaluation criteria, and build the response in their order. Answer every requirement on one line using the symbols the RFP defines, point to the page that proves it, and say plainly where you need a workaround or cannot comply. Use the question period. Prepare the supporting documents in Japanese: company overview, similar projects, team chart and a yen quote in their format.

Key Takeaways

• The evaluator reads with a scoring sheet in hand. Japanese government rules for IT procurement require the RFP to state how proposals should be written and how they will be scored, before anyone submits.
• Mandatory requirements can be a gate. In the procurement documents we cite below, a proposal that fails a single mandatory requirement can be disqualified before scoring starts.
• "Standard" and "workaround" score differently. A vague "Yes, configurable" leaves the evaluator to guess which category you meant.
• The forms are not suggestions. Some issuers forbid adding or deleting rows and columns in their answer sheets.
• The difference from US proposals is granularity, not principle. US federal RFPs also state instructions and evaluation factors in advance.

The Evaluator Cannot Score What They Cannot Find

A typical global proposal is built to persuade: an executive summary, the company story, platform overview, security, customer logos, pricing. It reads well in English, and a careful translation can read well in Japanese too. The problem is not the language. It is the order.

On the Japanese side, the person reading your proposal usually has a list of evaluation items with points next to each. They go down that list and look for your answer to item 3-2, then item 3-3. One published municipal tender, from Toyama City's water and sewerage bureau, asks bidders to match the item names and numbers in their proposal to the numbers in the evaluation criteria, and to add page numbers and an index (Toyama City). The point of that instruction is obvious once you see it: the evaluator wants to put your document next to the scoring sheet and read them side by side.

A translated template does not line up with anything. The answer to item 3-2 may exist, split across the platform overview and an appendix, but the evaluator has to search for it, and an answer that has to be searched for is easy to score low.

What a Japanese RFP Tells You Before You Write

For central government IT procurement, the rules are written down. The Digital Agency's standard guideline DS-100 says that when a system is procured by comprehensive evaluation, the RFP should, in principle, set out the content of the request (including how to write the proposal, the delivery structure and plan), the submission procedure, the evaluation criteria with the allocation of price and technical points, and the review method, such as presentations and Q&A (Digital Agency, DS-100, Part 3, Chapter 6). The same chapter treats the minimum mandatory requirements as base points that decide pass or fail, with additional points awarded on top. Evaluation looks at whether the proposal shows an accurate understanding of the requirements and whether it is feasible.

Municipal documents show what this looks like in practice. Yokohama City published, for one of its digital procurement projects, an evaluation item list with points and the specific viewpoints evaluators would apply, graded on two- to five-level scales (A to E) depending on the item, then converted to points. Separate items covered track record, the project manager and team leaders, functional requirements, information security and personal data protection, and the project structure chart (Yokohama City). Nagano City distributes its proposal forms as Excel files, including a functional requirements list, question forms for the RFP and the requirements definition, a cover sheet, a similar-projects record and a cost breakdown (Nagano City).

These are individual tenders, not a national template. The points, page limits and symbols differ from one issuer to the next, so read each RFP on its own terms. What they have in common is that the issuer tells you in advance what will be scored and where to put the answer.

Private-sector RFPs are less documented, and we have not found a public or industry source that defines a standard. From what we have seen, many Japanese companies borrow the same shape: a requirements list to answer line by line, a request for a company overview, similar implementations, a team structure and a quote. Treat that as an observation, not a rule, and follow whatever the RFP in front of you specifies.

The Requirements Sheet Is Scored Line by Line

The part of a Japanese RFP that most often surprises overseas vendors is the requirements compliance sheet. It lists each functional requirement on its own row and asks you to answer with a symbol.

Sapporo City's evaluation criteria for a network procurement are a clear example. Each mandatory functional requirement is marked A (met with standard functionality), B (met by an option or an alternative operation the city can accept) or fail (not met, or the alternative is not acceptable). Only proposals that pass every mandatory requirement go on to be scored for additional points, and a proposal can also fail if the basis or method of delivery remains unclear in answers to the city's questions (Sapporo City).

Toyama's instructions go further on format. The functional requirement answer sheets must not have rows or columns added or deleted, and each function is answered with a symbol: A for supported by the standard package with no customisation, B for supported through built-in settings or customisation, C for supported by a workaround, and D for not supported, with D answers heavily penalised. The same document asks bidders not to write their company or system name in the proposal, because it is reviewed anonymously (Toyama City). A logo-heavy global deck is simply not usable there.

English proposal habits do not fit this format well. "Yes, our platform is highly configurable" is a reasonable sales answer. On a Japanese answer sheet it is ambiguous: is that standard functionality, a paid option, or a customisation project? The evaluator either has to guess or ask, and neither works in your favour.

How to Build the Response

Keep the issuer's format exactly

If the requirement list is an Excel file, return the Excel file. Do not paste it into your proposal as an image, merge cells, add a "comments" column or rename the headings. Number the sections of your proposal to match the evaluation criteria, even if that means your company overview ends up near the back. If the RFP sets a page limit or paper size, treat it as a hard limit.

One requirement, one line, one page reference

Answer each row with the category the RFP defines, then one or two sentences on how the requirement is met, then the page in your proposal where the evaluator can check it. Read the definitions of each category carefully. In some RFPs, "configurable by an administrator" is standard functionality; in others, anything beyond the default package counts as customisation.

Do not hide gaps and workarounds

It is tempting to mark everything as fully supported. Where the RFP distinguishes standard support from alternatives, an honest B with a concrete alternative, including who does what and at what cost, is usually safer than an A that falls apart in the Q&A session. In the Sapporo criteria, an unclear basis in answers to questions is itself a ground for failure. If you cannot meet a requirement, say so in the format the RFP asks for and explain what you propose instead.

Use the question period

Public RFPs such as the ones above set a window for written questions, and some, like Nagano's, specify the question form. Under DS-100, important answers are shared with all bidders. Use it for anything ambiguous: the meaning of a requirement, whether a cloud service in another region is acceptable, whether English attachments are allowed. Write the questions in clear Japanese and keep each one to a single point.

Prepare the supporting documents in Japanese

Evaluators are scoring the people and the plan as well as the product. Prepare a Japanese company overview with legal entity, location and the Japan contact; similar projects described in the format requested, ideally in Japan or in a comparable sector; a team chart that names the roles, including who will handle the project in Japanese; a schedule; and a quote in yen using the issuer's cost form. Some issuers, such as Yokohama in the example above, score personal data protection and security as a separate item, so give them their own clearly labelled section.

How This Differs From a US Federal Proposal

It would be wrong to say that US RFPs leave vendors to guess. In the uniform contract format of the Federal Acquisition Regulation (FAR), instructions to offerors (Section L) and evaluation factors (Section M) are separate parts of the solicitation (FAR 15.204-1). Price must be evaluated, alongside non-price factors such as past performance and technical capability (FAR 15.304), and proposals are evaluated solely on the factors stated in the solicitation (FAR 15.305). Compliance matrices are common in US proposals as well. (FAR references are to the text published on acquisition.gov as of October 2026.)

The difference is one of form and granularity. FAR allows agencies to rate proposals with adjectives, colours, numbers or rankings, and to record strengths, deficiencies and risks, which leaves room for an overall judgement. The Japanese public documents above tend to publish point allocations in advance, distribute fixed answer sheets, and score requirements one row at a time, sometimes with a pass/fail gate before any additional points. A team used to writing persuasive narrative for Section L and M will need to switch to answering a form.

Checklist Before You Submit

1. Every form the RFP lists is included, in the file format it was distributed in, with no rows, columns or headings changed.
2. Proposal section numbers match the evaluation criteria, with page numbers and an index if requested.
3. Every requirement row has a category as defined in the RFP, a short explanation and a page reference.
4. Every B, workaround or "not supported" answer has a concrete alternative, with any extra cost reflected in the quote.
5. Questions were submitted in the question period, and published answers to other bidders' questions were read and reflected.
6. Company overview, similar projects, team chart, schedule and quote are in Japanese and in the specified format.
7. Page limits, paper size and anonymity rules are respected. No company name or logo where the RFP forbids it.
8. A fluent Japanese reader has checked the whole package, including terminology consistency between the proposal, the answer sheet and the quote.

Sources

• Digital Agency: Standard Guidelines for Promoting Digital Government (DS-100) (PDF, Part 3, Chapter 6)
• Sapporo City: comprehensive evaluation criteria (network procurement)
• Yokohama City: proposal evaluation criteria (FY2022, application management system for the Pittari Service integration)
• Toyama City Water and Sewerage Bureau: proposal preparation guidelines
• Nagano City: public proposal forms
• FAR 15.204-1, FAR 15.304, FAR 15.305

Frequently Asked Questions