Structured RFQ & Intake

From purchase request to RFQ, structured at every step.

Key Takeaway
When purchase requests arrive as scattered emails, context gets lost and RFQ quality varies by person. Centralizing intake ensures every sourcing event starts with a complete, traceable record.

The sourcing event begins when someone in your organization needs to buy something. Purchaser captures that request through a centralized channel (email or portal), assigns it to the right buyer, and tracks any clarification before the RFQ is created. Team-level templates ensure the final RFQ is consistent regardless of who creates it.

Your team

  • Submits the purchase request
  • Clarifies requirements when asked
  • Defines scope boundaries
  • Sets the vendor list and submission deadline.

Purchaser

  • Captures and logs the request
  • Routes it to the right buyer
  • Tracks clarification
  • Applies team templates
  • Distributes the RFQ to invited vendors.

Input

  • Purchase request (email or portal), specifications, vendor list

Output

  • Structured RFQ record linked to the original request, with full intake audit trail.

What breaks without this

When purchase requests arrive as emails to individual buyers, context gets lost in forwarding chains. Each buyer drafts their own RFQ from scratch, with different wording and different levels of detail. The result: vendors receive inconsistent requirements and fill in the gaps with their own assumptions.


Vendor Submission Normalization

Heterogeneous submissions aligned to a common evaluation structure.

Key Takeaway
You can't compare bids fairly until they're in the same format. Normalization makes that possible.

Normalization is the process of transforming vendor submissions, which arrive in incompatible formats like PDFs, Excel workbooks, and email attachments, into a common format for comparison. Purchaser extracts and normalizes every submission against the RFQ structure before evaluation begins.

Your team

  • Reviews the normalization output
  • Resolves flagged ambiguities
  • Confirms the submission registry is complete.

Purchaser

  • Extracts line items from every submission format
  • Maps vendor line items to RFQ requirements via Smart Mapping
  • Flags gaps and additions against the RFQ baseline
  • Tracks quote versions through negotiation.

Input

  • Vendor submissions (PDF, Excel, email, portal exports)

Output

  • Structured comparison: every vendor mapped to the same line-item structure.

What breaks without this

Without normalization, comparing submissions means comparing the vendors' organizational logic, not their actual bids. Price differences reflect structural formatting choices, not genuine cost differences.


Technical & Commercial Evaluation

Scope compliance established before pricing enters the evaluation.

Key Takeaway
Review technical scope before price to prevent low bids that exclude required work from anchoring the evaluation.

Technical compliance, whether each vendor's submission actually covers the required scope, is evaluated before commercial pricing is considered. This sequencing prevents price from anchoring the evaluation before scope deviations (cases where a vendor's submission differs from what was requested in scope, specification, or quantity) have been identified. Purchaser surfaces all deviations and flags them for team review.

Your team

  • Reviews deviation flags
  • Conducts technical scoring against predefined criteria
  • Makes scope clarification decisions
  • Applies commercial weighting.

Purchaser

  • Generates the structured comparison view
  • Surfaces deviations by line item
  • Produces the evaluation matrix calibrated to the team's criteria.

Input

  • Structured comparison, evaluation criteria.

Output

  • Deviation flag report + structured evaluation matrix with scores.

What breaks without this

When pricing enters the room before scope has been established, evaluators anchor on price. Scope gaps get rationalized rather than resolved. The result is a low bid that undercovers the actual scope, a change order waiting to happen.


Portfolio Visibility & Control

Consistent process maintained across simultaneous sourcing events.

Key Takeaway
When every package uses the same process, portfolio-level patterns become visible without manual coordination.

Capital project procurement rarely operates on a single RFQ at a time. Purchaser maintains the same process across every concurrent sourcing event, so the normalization, evaluation, and documentation produced for Package A is consistent with Package B, C, and D running in parallel.

Your team

  • Monitors active package status
  • Allocates evaluation resources across concurrent events
  • Coordinates cross-package vendor relationships.

Purchaser

  • Applies consistent defaults across all active events
  • Tracks submission status by package
  • Surfaces portfolio-level visibility without manual aggregation.

Input

  • Multiple concurrent RFQ packages.

Output

  • Portfolio status view: all active events in a consistent state.

What breaks without this

Without consistency across packages, each procurement event becomes its own improvised process. Portfolio visibility requires manual coordination. Mistakes made in one package are repeated in the next.


Governance & Award Traceability

Complete, auditable record from inquiry through award recommendation.

Key Takeaway
A real audit trail is generated at each stage, not assembled retroactively when someone questions the award.

The award recommendation is supported by a complete, traceable record: the original RFQ, all vendor submissions, the normalization output, the evaluation matrix, and the decision rationale. This record is produced as a natural output of the structured process, not assembled retroactively.

Your team

  • Reviews the award recommendation
  • Documents the final decision rationale
  • Obtains required approvals
  • Issues the purchase order.

Purchaser

  • Compiles the complete audit trail from intake through evaluation
  • Produces the award recommendation summary
  • Packages all documentation for stakeholder review.

Input

  • Completed evaluation matrix, decision rationale.

Output

  • Award recommendation with complete audit trail, from intake to decision.

What breaks without this

Governance imposed at award on a process that was ambiguous from intake through evaluation is retrospective documentation, not a real audit trail. It cannot reconstruct the decision with integrity.