Monday morning, an estimator opens an invitation from a bid portal. The coordinator has already entered the project in Bid Register - FINAL.xlsx. The drawing set is in Shared Drive/Estimating/2026/New Opportunities/Northbank, but an addendum is still sitting in another employee's inbox. A revised due date appears on the portal. The estimator's notes are in a private notebook.
Everyone is working. Nobody is looking at the same RFQ.
This is a representative operating scenario using invented names and values. It is not a client case study or published client result.
What the team had before
Email
├── Invitation to tender.eml
├── Addendum 02.eml
└── Clarification response.eml
Shared Drive/Estimating/2026/New Opportunities/Northbank/
├── Drawings/
│ ├── Tender_Set_RevA.pdf
│ └── Tender_Set_FINAL.pdf
├── Specifications/
│ └── Concrete_Specification.pdf
├── Quotes/
│ └── Supplier_Quote_14.xlsx
└── Submission/
└── Northbank_Bid_v7_FINAL_FINAL.xlsx
Bid portal
├── Original invitation
├── Current due date
└── Addendum 03
Bid Register - FINAL.xlsx
└── One row showing project, estimator and due date
The spreadsheet was not necessarily wrong. It simply could not preserve the complete operating history.
Where the work broke
- The portal due date changed, but the spreadsheet did not.
- Two files looked current because neither had a controlled revision state.
- The estimator was assigned, but there was no acknowledgement.
- Clarifications were separated from the affected scope.
- The final submission could not be traced to the exact approved estimate.
- Follow-up and loss reasons were stored inconsistently.
The controlled workflow
A controlled path captures the source evidence, checks whether the project already exists, registers the current documents, assigns accountable ownership, preserves clarification and review, holds external issue until commercial approval, and records submission and outcome.
Uncertain matches enter a review queue. Incomplete approval becomes an explicit exception. Neither state is resolved through a silent overwrite.
The system does not replace estimating judgement. It preserves the evidence around that judgement.
What gets built
The operating layer usually needs connected records for:
- Opportunity and source
- Company, contact, project and site
- Drawing, specification, addendum and revision
- Estimator, reviewer and approver
- Due date and controlling source
- Clarification and exception
- Estimate version and submission
- Follow-up, decision and outcome reason
Each record retains an owner, status, dates, relationships and history. Conflicting dates or uncertain matches become visible work instead of silent spreadsheet edits.
Decide which source controls each value
A shared record should not erase source disagreement. The workflow needs a rule or accountable reviewer for deciding which due date, revision, scope instruction, contact, and approval state controls the next action.
Where the difference matters, retain both values with their source, retrieval time, resolution, and responsible person. That history lets the team explain why a deadline or document state changed instead of presenting the latest cell as if it had always been correct.
What the business receives
- One RFQ control queue
- Current-document view
- Ownership and acknowledgement states
- Due-date and exception alerts
- Approval and submission history
- Pipeline and outcome reporting
- Handover documentation and operating rules
Minimum acceptance test
Before the workflow is accepted, representative test cases should confirm that it can:
- Preserve the original invitation and source reference.
- Flag a possible duplicate without forcing an automatic merge.
- Show a conflicting due date and identify the controlling decision.
- Link an addendum to the affected opportunity, documents, and estimate.
- Record estimator assignment and acknowledgement separately.
- Block issue when required commercial approval is incomplete.
- Trace a submission to the approved estimate version and delivery evidence.
- Surface failed intake, missing files, and stale source data in a review queue.
The implementation also needs a named monitoring owner, recovery instructions, and a disable path when a source, login flow, export, or interface changes.
Illustrative time-value calculation
Assume a team handles 35 RFQs per month and spends an average of 25 minutes per RFQ searching for files, checking dates, and reconciling status.
35 RFQs × 25 minutes = 875 minutes
875 ÷ 60 = 14.6 hours per month
14.6 hours × $65 loaded hourly cost = $949 per month
That calculation is a planning example, not a promised saving. A real baseline must measure the client's volumes, time, error rate, rework, and labour cost before implementation.
The larger value may not be administrative time. It may be avoiding one missed addendum, late submission, unapproved price, or lost follow-up. Those events still need a real baseline and observed evidence before they can be represented as results.
Explore the RFQ-to-Bid blueprint or map your current RFQ path.
