Follow up on the decision behind the quote.

Keep the account, opportunity, quote reference, revision, sent date and responsible person connected. Record which version was sent, not only which version was most recently edited. A draft on your system may differ from the document the customer is reviewing.

Use the actual states your quoting system supports. Microsoft’s Dynamics 365 example distinguishes draft, active and revised quotes. Your process may differ, but it still needs to show the current customer-facing version and what replaced an earlier one. Resolve missing quantities and terms using the RFQ review checklist.

Write the next unresolved question in ordinary language. Does the engineer need to confirm a specification? Is procurement comparing approved options? Does another site need to agree the delivery arrangement? Keep the evidence for that statement beside it; “waiting for budget” should not be a guess copied forward every week.

Add who owns the next action, any date agreed with the customer and the reason to revisit it. If no next step was agreed, make that the question for the account owner. Quote age can prompt a review, but it cannot explain the customer’s reason for silence. Keep a customer-agreed date distinct from an internal target: a review date your team selected is not a commitment from the buyer.

Give the next contact a clear purpose: answer a question, confirm a changed requirement or ask about decision timing. Prepare the relevant document and history so the account owner can contribute something specific. An elapsed timer alone is a weak reason to send a reminder.

Respect the channel, relationship, recorded exclusions and any agreed pause. A request to come back after an internal review should remain visible when a new person takes over the account. Drafting a reminder and deciding to send it are separate actions.

A manufacturer sends revision 1 of a quote on Monday. On Tuesday, the customer asks whether a different material will meet the specification. The estimator prepares revision 2, which needs engineering approval before release.

The next action is an internal technical check, not a customer chase. The record shows revision 1 as the version the customer holds, revision 2 as a draft, the open material question and the engineer who owns it. The account owner can explain the status without promising an unapproved answer.

Once engineering approves revision 2 and the customer has the correct revision, record the actual sent version and date and retain revision 1. Record a customer review date only if agreed; otherwise leave it unagreed. A task created for revision 1 must use the new context and cannot send the outdated attachment.

A colleague covering the account should be able to find five things without asking the original owner: the version the customer holds, the unresolved question, the source of the latest change, the person responsible and the next review condition. Keep these in the opportunity record or an explicitly linked quoting record, rather than scattering them across unrelated tasks.

If the question came from a call, link the checked call note to the quote. If a new technical or procurement participant is needed, use the stakeholder map to record why they are involved and how the introduction should happen. Sending the quote to more people is not a substitute for understanding their roles.

A reminder workflow can prepare the record and flag a missing owner or elapsed review date. It should hold when the revision is uncertain, the opportunity is paused or approval is outstanding. Test a repeated event so the same change cannot create several tasks or send several copies of the proposal.

Keep the reason for the revision and the fields that changed. Quantity, specification, delivery requirement and price can each require a different approver. Preserve the source request and avoid treating an internal draft as the customer’s acceptance of a changed term.

When an opportunity pauses, record who can restart it and what must be checked first. Reopening may require fresh checks on availability, specification or commercial approval. Make those requirements visible before anyone reuses the last quote.

Agree what evidence closes the opportunity. A received order, a customer decision to use another option and an unresponsive account are different facts. Keep the customer’s reason where it is known; keep it unknown where it is not. Do not let a model invent a loss reason from the age of the quote. The win-loss review keeps buyer-confirmed reasons separate from team interpretations and unknown outcomes.

Review the closed and still-open group together. Compare similar types of work and allow time for decisions to mature. The measurement guide explains why a set of successful quotes alone cannot show which follow-up caused the wins.

Choose five quotes with different states. For each, identify the version the customer has, the next unresolved decision, the owner and the next justified action. Ask another colleague to reconstruct the situation from the record. Add whatever they had to ask you for.

Take unresolved dependencies into the pipeline review so the team can assign the help needed. A sent reminder is an activity; an answered specification question or an agreed next step is a different kind of progress.

Before automating, test a revised quote, an absent owner, a paused opportunity and a repeated event. You can commission a standalone quote-review workflow through AI Workflows. Within a Build campaign, agree which proposal context and handovers the campaign needs. The implementation plan helps define what will be released and who approves it.

If useful preparation depends on a missing specification process or unreliable records, include those dependencies in the agreed scope. Keep the initial task focused on a handover the team can use and review, with sales calls, prices and closing remaining your team’s responsibility.