An introduction to writing a ringi

What is a ringi? A document that supports a decision

A ringi explains a proposed purchase, contract or other action so that people within an organization can review and approve it. It sets out what you want to do, why, and within what scope, in a form that helps readers decide.

Forms and approval routes differ between organizations. First check your internal format and the procedure for the amount and type of request. Use this guide to organize your explanation, not to fill in as many fields as possible.

Think about who will read it

Depending on the request, readers may include your manager, accounting, IT and the final approver. Briefly explain abbreviations and assumptions when they first appear, so that people unfamiliar with your daily work can follow.

• Operational readers: What is the problem, and how would the work change?
• Financial readers: What expenditure is needed, how much, and over what period?
• Approvers: What is being decided now, what are the alternatives to proceeding, and what risks remain?

State the decision you need at the beginning

Approval to investigate an option is not approval to place an order. Start with the known scope: the people or items affected, quantity, period and amount. This gives the rest of the explanation a clear frame.

A title such as 「会議室の改善について」 (About improving the meeting room) is broad. A request to consider replacing one monitor in Meeting Room 3 can specify that the formal quotation is still being checked and that the present decision concerns choosing a model, not ordering it. If you are seeking approval to order, make that scope explicit instead.

Separate background, purpose and proposal

Background describes what is happening now; purpose describes the problem you want to solve; the proposal describes what you want to do about it. Combining them can make a purchase appear to be an end in itself. The Japanese example keeps these roles separate.

背景：会議室モニターで接続不良が起きています。発生頻度は未集計です。
目的：会議開始時の接続トラブルを減らしたいと考えています。
提案：モニター1台の更新を検討します。原因が配線にある可能性も残っています。

Make costs and benefits comparable

Separate one-off and recurring costs, tax-inclusive and tax-exclusive amounts, and monthly and annual charges. Compare alternatives over the same period and for the same number of users. Show known operating or cancellation costs separately from setup costs.

Distinguish measured results from expected benefits. Do not turn an expectation of less work into a percentage reduction or monetary saving without evidence. An estimate of time saved should identify the work, measurement period and method, and remain clearly labeled as an estimate.

• Give each number its unit, scope, period and evidence.
• Do not mix estimates with confirmed amounts, or actual results with forecasts.
• Describe unmeasured benefits as qualitative expectations.

Include risks, alternatives and the option not to proceed

Benefits alone do not let readers compare options. Identify relevant concerns such as migration work, operating effort or the possibility that people will not adopt the tool. If a mitigation has not been agreed, do not present it as settled.

Compare realistic alternatives, including keeping the current arrangement, repairing equipment or running a limited trial. Separate known consequences of not proceeding from possibilities. Avoid unsupported claims that an immediate purchase is necessary to prevent certain losses.

Keep uncertainty visible and connect it to the decision

Do not invent amounts or dates to make a document look complete. Keep unknowns, estimates and checks in progress visible, and explain what can be decided with that information. Name an owner or deadline for a check only if one has been agreed.

「月額10万円の見込み。正式見積は確認中」 (an estimated monthly cost of ¥100,000, with the formal quotation being checked) does not mean the same as a confirmed monthly cost. Requiring both conditions A and B also differs from requiring either one. Do not remove certainty levels or conditions when shortening a draft.

Common problems and how to improve them

• A long background hides the request: put the decision needed into one sentence at the start.
• Benefits are described only as convenience or efficiency: explain which work would change and how, within what the evidence supports.
• Only the preferred option is emphasized: include the alternatives considered and the option to keep the current arrangement.
• Unfavorable conditions or unknowns are omitted: keep them where readers can see their effect on the decision.

Check before submitting

• Is it clear what approval covers and what is out of scope?
• Are cost units, periods and tax treatment consistent?
• Can readers distinguish evidence from expected benefits?
• Have you explained risks, alternatives and the consequences of not proceeding?
• Have you retained unknowns, conditions and prohibitions?
• Can a reader unfamiliar with the subject quickly understand the decision?