A good ROM estimate email states what the range covers, why it is a range and what happens next. Include the estimate’s purpose, fee basis, important assumptions and review point. The six examples below are editable communication patterns; their amounts and conditions must match your actual scope and approval.
Terms used in this guide. fee: the amount charged to the client; cost: the expense included in the stated project model; margin: revenue left after the included costs; margin percentage = that amount / revenue × 100; ROM: rough order of magnitude: an early estimate for a planning decision.
In plain words
When you send a ROM, the email is the part the client keeps. A good one says what the range covers, why it is a range, what the main assumptions are and what happens next. Written well, it reduces the chance that the client treats a rough range as a fixed price. The label alone does not settle what either side has agreed, so the wording and the assumptions matter.
Who this helps: Presales consultants, account managers and project managers who send early estimates.
Questions this guide answers:
- How do you write a ROM estimate email?
- What should a ROM proposal or quotation email say?
- What wording avoids confusion about a ROM?
Read first: What is a ROM estimate? explains the basics and the lifecycle this guide builds on.
What should a ROM estimate email contain?
Write the email in the order the reader needs it, so the number still makes sense when it is forwarded without the call behind it. A senior stakeholder should understand why the low and high cases differ without opening a spreadsheet.
| Part | What to write | Example |
|---|---|---|
| Subject line | Project and status | Customer portal: planning estimate for scope review |
| Opening sentence | The decision you want from the reader | We are seeking your feedback on budget before a firm proposal. |
| The range | One currency; client fee or cost, stated; tax stated | USD 50,000–65,000 client fee, excluding tax |
| The condition | The one unknown that moves it most | Depends on how many systems connect and on data quality. |
| Scope reference | One versioned scope note, named the same everywhere | Portal scope note v2 |
| Status and next step | Not a quote; what happens next | Not a quote. We will confirm after a two-day discovery. |
A generic “subject to change” is weaker than naming the condition that changes the estimate. Keep internal delivery cost out of the client email unless there is an approved reason to share it; internally, sales and delivery should see the scope, effort, cost and margin checks behind the range, and nothing should leave until it has passed them. These examples are client fee ranges excluding tax. They do not decide whether an exchange creates obligations: use the wording your organization and the buyer’s procurement process require. For why the framing matters, see how to present a ROM without anchoring.
Six ROM estimate email examples for different client conversations
- After the first call. “For the portal scope discussed today, our budget-planning ROM is a client fee of USD 50,000–65,000, excluding tax. It assumes one documented integration and existing content. Data migration is not included. We suggest validating access and sample records before preparing a firm proposal.”
- After discovery. “Discovery confirmed the standard API but found custom approval rules. Our revised planning range is USD 58,000–68,000 for the attached backlog. The remaining uncertainty is your approval workflow, which we will review with your operations lead on Friday.”
- When the client wants one figure. “If you need one budget allowance, we can document a USD 65,000 planning scenario for the stated scope. It is a budgeting assumption, not a fixed-price offer, and the range stays beside it. Before commitment we need to test the API and agree acceptance criteria.”
- When the budget is lower. “At USD 40,000 we recommend a first phase covering sign-in, customer profiles and read-only orders; uploads and notifications would follow. The original USD 50,000–65,000 range covered all five capabilities. Shall we review the reduced phase against your immediate need?”
- When the ROM increases. “The original ROM assumed clean source data. Sample testing shows duplicate accounts and missing identifiers. Adding the agreed cleanup changes the planning range to USD 64,000–78,000. The attached comparison separates the additional work from the original scope.”
- When proposing paid discovery. “We recommend a two-week discovery at a fixed fee of USD 12,000, producing the integration findings, a prioritized backlog and a delivery estimate. Implementation is separate. We will present delivery options afterwards rather than commit to an untested build price.”
What each one is doing, and what to check before sending.
- First call: it gives the buyer an affordability answer and names one integration and one exclusion. Check that those boundaries match the conversation: if the prospect kept mentioning historical records, excluding migration without saying so makes the range neat but misleading.
- Discovery and increase: show a bridge from the old range to the new one, separating new scope (“custom approval rules were added”) from corrected assumptions (“the original rules take more effort than assumed”), and name the evidence that caused the change.
- One figure: choose the allowance through a risk decision, not the midpoint, and keep the supporting range and conditions on file.
- Lower budget: change the scope visibly; never imply the complete original portal fits the smaller amount.
- Paid discovery: state the outputs, who takes part and the readout decision. Make “the project is not viable” a valid outcome: the client is buying evidence and options, not a guarantee.
Which wording in a ROM email causes confusion?
| Risky wording | Why | Better |
|---|---|---|
| “This will cost $50k” | The amount is still a scenario | “Our planning range is USD 50,000–65,000, excluding tax” |
| “Everything included” | No named deliverables or boundaries | List what is included and one or two key exclusions |
| “Plus or minus 20%” | No explanation of the low and high cases | “Lower if the API is standard; higher if reconciliation is custom” |
| “Valid for 30 days” | A major technical assumption stays unstated | Say which assumption the number depends on |
Before sending: read it as someone who was not on the call
- Does “the portal” mean a specific phase?
- Does “including integration” mean one interface or all future ones?
- Does the amount include tax, expenses and software subscriptions?
Keep a record
- Use the same scope labels in the email, the estimate sheet and the presentation.
- When a number changes, keep the previous version and add a short note of what changed and what still needs validation.
- Record the sent version, date, recipient and supporting estimate, so the later proposal and the delivery handover can use them.
How much detail should a ROM email include?
Enough to understand the decision and the biggest qualification. Put detailed work packages and assumptions in an accessible attachment or linked document, with a version and owner. Do not bury the only mention of an excluded integration in fine print while the email promises a complete portal.
Real example: an account manager rewrites a ROM email
An illustrative story with invented figures, to show how the idea works in a real office.
Maya, an account manager, drafts: “The project will cost USD 60,000.” The presales lead points out that nobody has scoped it.
She rewrites it: “For budgeting only: our fee would be somewhere between USD 45,000 and USD 80,000, based on two similar projects. The range depends on how many systems we connect and the quality of your data. This is not a quote. We will confirm the figure after a two-day discovery.”
The new email has a range, a reason, a warning and a next step. The client replies with the number of systems, which is exactly what Maya needed.
When in the sales cycle do you send a ROM email?
The email is the version of the ROM that the client keeps and forwards, so it gets its own checkpoint. A presales consultant drafts it; the presales lead reads it as someone outside the call would.
| Moment | Who drafts and who reviews | Checkpoint before sending |
|---|---|---|
| After the first call | Presales consultant drafts; presales lead reviews | Price range (not cost), one named unknown, “not a quote”, next step |
| After discovery | Presales consultant and delivery lead; presales lead reviews | What changed since the last range, and which evidence caused it |
| When the budget is lower | Account manager with the presales lead | The reduced scope is visible; the original range is not quietly reused |
| When the range goes up | Presales lead, with the account manager on the call | A bridge from the old range to the new one, in the same scope labels |
| Before filing | Account manager | Sent version, date, recipient and supporting estimate recorded together |
Downstream, the client uses the email to plan a budget and to ask for a firmer estimate; later the project manager receiving the deal compares the delivered cost against it.
ROM estimate emails: frequently asked questions
Should the email contain every assumption?
Include the major qualification and decision-critical exclusions in the message, then refer to the detailed versioned scope note. An attachment should extend the explanation rather than hide a condition that contradicts the main email. Use concise language that survives forwarding.
What should I ask the client to do next?
Choose one action that resolves the current decision: confirm the budget envelope, provide representative data, nominate an approver or approve discovery. A general invitation to discuss may be friendly, but a specific evidence request makes the next estimate revision more useful.
Should I include my hourly rates in the email?
Follow the agreed offer process, confidentiality policy and the buyer’s procurement requirements. Include rates when needed to explain the commercial basis; a request for a ROM alone does not settle what must be disclosed.
How long should a ROM email be?
Short enough to be read: purpose, range, three assumptions, exclusions and next step. Link or attach detail rather than expanding the body.
Can I send a ROM without sales approval?
Follow your firm’s rule. Many firms require sales and delivery agreement on the range, because the number will be quoted back.
How do you get the ROM numbers from Managed Margin?
Build and review the fee scenario before writing the message. For the portal example, use the actual role effort, approved planning rates and applicable costs in an estimation strategy. If the buyer asks for one planning allowance, test that offered figure with Quoted Price and inspect the margin it leaves. Keep the scope assumptions associated with the saved version.
Use the approved scenario's price and scope in the email's decision sentence, then explain the main unresolved condition in plain language. Managed Margin supplies the financial basis; your normal email and proposal process supplies the client communication. When discovery changes effort, create or revise a draft alternative and explain the difference before sending a revised range. It does not write the six messages for you.
Explore the pricing and estimation workflow or review the delivery margin workflow.
Background reading: giving a ROM estimate without anchoring the client and what is a ROM estimate?.
Continue the sequence: guides to read next
- ROM Cost Estimate Examples for IT Projects: the calculations the email summarizes
- How to Present a ROM Estimate to a Client Without Anchoring: the thinking behind wording that prevents anchoring
- What Is a ROM Estimate? Meaning, Cost and Example: the definition to put in the email footer
Sources and methodology
The worked figures are original educational illustrations. The linked references provide background for the estimating and management concepts; they do not establish the example rates or guarantee the outcomes. Product instructions describe the current implementation and are separate from methods the reader performs outside the application.
The examples, templates and calculations are original editorial illustrations, not market benchmarks or customer results. Monetary amounts are in USD, exclude tax unless stated, and use the cost boundaries defined in the article. Validate assumptions against your own delivery history before quoting.
Further background: PMI: estimating basics (PM101). The worked arithmetic and scenarios above are original; this reference provides context and is not a source for market rates or the stated example amounts.
The application walkthrough was checked against the current stage, pricing, cost-rule and delivery calculation code on 13 October 2026. Forecasts describe recorded actuals plus the remaining plan, not predicted customer outcomes.