Replacing an Excel quote tracker: fix price and version errors

A customer accepts a quotation. The office still has the first version, sales has changed the quantity, and purchasing now uses a different price. Before building a new interface, you need a reliable way to connect those changes to the same quotation.

Start with one disputed quote. It can reveal the missing rules and whether your existing tools can support them. Excel supports co-authoring with a suitable setup; having several contributors alone does not justify replacing it.

One quotation, three specific conflicts

This example is hypothetical. A business sells product A. The identifiers and quantities are invented to explain the process.

If the customer accepts version 1, the system must not silently create an order for 18 units. Whether the earlier price remains valid depends on the agreed terms. The software needs to make the basis of that decision traceable.

Decide which version takes precedence

In this example, every quotation needs a stable identifier. Changes produce recognisable versions. Keep the actual line items and price record used for each version sent to the customer. A later price change must not silently overwrite that history.

A possible process is: draft → internally checked → sent → accepted or declined. A new version returns to draft. This is a suggested working model. Your business still needs to decide how to handle acceptance of an older version.

Q-105 is initially flagged as a possible duplicate. Matching customer names are insufficient for automatic merging: the customer may have sent two similar enquiries.

Compare solutions using this transaction

A well-organised shared spreadsheet may suffice when a small team can operate the process reliably and checking remains manageable. First try stable identifiers, defined statuses and a reliable record of sent versions.

A CRM is worth assessing when customer communication, follow-up and quotations are the main tasks. Ask the supplier to demonstrate Q-104 in the proposed product. Can it handle multiple versions, unchanged records of what was sent and the approvals you need? A general feature name does not answer those questions.

A custom application becomes worth investigating when unusual calculations, multiple system connections or specific approval rules remain unresolved after testing available products. Record the outstanding case. It gives you a reason for the additional development scope.

Run three tests before deciding

Run the same tests in every solution you seriously consider. An answer such as “only with another module” belongs in the scope and cost comparison.

Limit the first implementation

Quotations, versions, sending and acceptance may be enough for the first step. You do not need to rebuild stock management and accounting at the same time. You do need to identify where an accepted quotation enters the existing system and how a failed transfer becomes visible.

Compare setup, migration, ongoing use, maintenance and later changes for the same scope. A cost comparison that omits a required integration is incomplete.

An anonymised description of your most troublesome quotation is a useful starting point for an implementation discussion. ASES can use it with you to assess the business rule, existing options and an appropriate first scope.

Sources

• Microsoft: Co-authoring Excel workbooks. The transactions and solution comparisons are original editorial examples.