How to Compare NetSuite Proposals Using an Assumption Register

Two NetSuite implementation proposals can describe the same business and still price different projects. One may include data preparation, repeated trial loads and operational training. Another may assume the customer completes those tasks before consultants begin. Comparing the totals alone hides the difference.

A defensible comparison starts with a shared baseline and an assumption register. The register records what each proposal includes, excludes, assumes or leaves unanswered. It gives procurement a way to ask precise questions and gives the CFO a clearer view of the total commitment.

The aim is not to force every supplier into an identical delivery method. It is to understand which differences are deliberate, what they mean for the business and who carries the resulting responsibilities.

Establish one comparison baseline

Prepare a short scope statement before reviewing commercial terms. Identify the entities, processes, locations, reporting outcomes, integrations and migration populations needed for the proposed launch. Include the planned role of internal teams and any non-negotiable operating constraints.

Use the same baseline for every bidder. If a provider proposes a narrower first phase, record it as an alternative rather than quietly comparing it with a broader proposal. Alternative designs can be valuable when their consequences are explicit.

Define the comparison period as well. A first-year view may conceal support obligations, temporary interfaces or later phases. Show implementation cash, internal capacity and recurring costs separately, then compare them over the organization’s chosen planning horizon.

Build an assumption register with evidence

For each item, capture the baseline requirement, each bidder’s written position, the evidence location, the unresolved question and the party responsible for closing it. Useful statuses are included, excluded, customer-owned, conditional and unanswered.

Do not use “included” when the proposal merely mentions a topic. “Data migration included” could mean file import assistance, while the business expects extraction, cleanup, mapping, reconciliation and multiple rehearsals. Break broad phrases into deliverables that can be verified.

Add a consequence field. An unanswered question matters because it could affect effort, schedule, controls or operating continuity. Naming that consequence helps prioritize clarification instead of sending a long undifferentiated list of questions.

A worked side-by-side comparison

The following register is entirely hypothetical. Provider A and Provider B are anonymous illustrative bidders, not descriptions of real firms or quotations. The buyer is planning a finance and inventory launch with one operational interface.

Migration

The baseline requires approved master data, opening balances, open transactions, two planned trial loads and reconciliation evidence. Provider A includes mapping workshops and two loads but assigns source cleanup to the customer. Provider B includes one load and assumes import-ready files.

The clarification is specific: who corrects rejected records, what constitutes a completed load, and what happens if reconciliation reveals a mapping defect? The internal finance effort must appear in both scenarios. Provider B’s narrower service is not automatically inferior, but it may demand more customer capacity.

Integration

The baseline requires transaction transfer, exception notification, duplicate prevention and a reconciliation report. Provider A describes normal processing and testing but leaves monitoring ownership unclear. Provider B names a technical owner and support boundary but excludes changes to the external application.

The buyer should resolve monitoring ownership in A and confirm external-system responsibilities in B. Neither proposal should receive full credit merely for saying “integration included.” The relevant outcome is an interface the business can operate and recover when something fails.

Training

The baseline requires finance and warehouse staff to complete role-specific scenarios. Provider A offers workshops for designated superusers. Provider B lists end-user sessions but does not state who prepares training data or materials.

The clarification should establish audience, session scope, practice environment, materials, attendance responsibility and evidence of readiness. Counting training hours without understanding the delivery model gives a misleading comparison.

Post-launch support

The baseline requires coverage through the agreed stabilization milestones and a handover to normal support. Provider A offers a fixed period with specified hours. Provider B offers milestone-based support but has not defined the exit criteria.

Ask how urgent incidents are triaged, which hours apply, what support excludes and what happens to unresolved defects at the boundary. Compare the actual protection offered rather than preferring a longer duration by default.

Change requests

Both proposals require approval for additional work. Provider A treats newly discovered requirements as changes. Provider B also identifies customer delays and additional test cycles as possible charge triggers.

The buyer needs a shared understanding of what constitutes a defect, an assumption failure or new scope. Ask each bidder to walk through the same example, such as an agreed workflow failing an acceptance scenario, and explain how it would be handled.

Normalize costs without inventing precision

Create a normalized view with the quoted amount, identified customer work, separately priced options and unresolved exposure. Where a missing item can be estimated credibly, show the basis and confidence level. Where it cannot, keep it unresolved rather than manufacturing an adjustment.

Do not convert every risk into a guessed monetary amount. Some risks are better treated as conditions of selection, such as naming the delivery lead or proving a critical workflow. The purpose is an informed decision, not a spreadsheet that disguises uncertainty behind decimals.

Make internal capacity visible. If one delivery approach requires the controller for twice as many workshops, procurement should understand the scheduling consequence even when it creates no immediate invoice.

Test the proposed team and delivery model

Ask who will actually lead design, migration, integrations and testing. Request expected allocation, relevant experience and the process for staffing changes. Distinguish sales participation from delivery responsibility.

Run a short scenario with the proposed team. Present a disputed requirement or a failed reconciliation and ask how they would investigate, decide and escalate. Listen for clear ownership and evidence requirements. A polished methodology document is useful, but the team’s reasoning during a concrete problem is more revealing.

Also ask what the provider needs from you. A credible proposal should state customer decisions, data, access and staffing dependencies openly.

Questions procurement teams ask

Must every proposal use the same commercial model?

No. Different models can be compared if deliverables, assumptions and risk allocation are explicit. Understand how each model handles uncertainty and what evidence supports its estimate.

Should we reject a proposal with exclusions?

Exclusions are normal and useful when clearly stated. The problem is an exclusion that nobody owns, or one that prevents the agreed business outcome from being achieved.

How many clarification rounds are reasonable?

Use the material gaps to decide. Stop when the decision-critical assumptions are understood and reflected in the written proposal. Repeated vague answers are themselves relevant evidence.

Can the assumption register become part of contracting?

It can support scope discussions and document review. Have the appropriate commercial and legal reviewers determine how it should relate to the final agreement and statement of work.

Choose the delivery commitment you understand

A good comparison explains why prices differ and which responsibilities the business is accepting. Bring your scope baseline and unresolved assumptions to CuriousRubik to discuss the questions that should be settled before a NetSuite implementation decision.