Carlos EscasainCommercial Systems & Process Architect
ENES

Operating Model & Process Design / 03 · Classification → assessments → decision rights

Standardizing RFQ governance across commercial, technical, compliance and project decisions

A fictional, composite case about long-cycle OEM and private-label requests. Not an approval flow—the governance model that decides which requests to pursue, with whose judgement and on what evidence.

Fictional scenario11 min readUpdated 29 Sep 2026
Fictional scenario

Independently created. Contains no employer or client implementation detail, internal names or figures.

The case in brief

Current reality

Complex RFQs were decided by whoever was copied on the email: some got engineering, quality and finance review, others were quoted before anyone checked feasibility.

What must become true

Every complex RFQ is classified on entry, assessed by the functions its class requires, decided Go / No-Go by a named owner on recorded evidence and within a clock—and the decision can be audited later.

Design question

Which judgement does each kind of request need before the company commits—and who is allowed to make that call?

01Reality

What the organization actually did.

A fictional industrial supplier receives requests for information and quotation from equipment makers (OEM) and from customers who want products under their own brand (private label). One request can mean a new product, new tooling, plant capacity, quality validation, compliance checks and a multi-year ramp-up. Commercial, engineering, quality, plant, finance, purchasing and compliance each held part of the judgement; none held the decision.

  • RFIs and RFQs arrived through the same channel and were treated the same way
  • Some requests were priced before engineering had seen the drawing
  • Feasibility, quality and compliance reviews happened by email, with no record of who concluded what
  • Investment and capacity questions surfaced after the offer had been sent
  • The same kind of request got a different review depending on the account manager
  • No-Go decisions were rarely recorded; declined requests simply went quiet
  • OEM and private-label requests ran on separate habits, with overlapping but inconsistent rules

02One process?

What made one process insufficient?

Treating every request alike either buried simple ones under reviews or let consequential ones through without them. These variables decided how much judgement a request needed:

  1. RFI or RFQIs the customer exploring, or asking for a binding offer?
  2. Product and technology noveltyAn existing reference, a variant, or a new development?
  3. Lifetime value and marginWhat is the programme worth over its life, and at what margin?
  4. InvestmentDoes it need tooling, equipment or other capital before the first delivery?
  5. Industrial feasibilityCan a plant make it at the volumes and ramp-up requested?
  6. Quality and validationWhich validation, testing and approvals does the customer require?
  7. ComplianceWhich regulatory, trade or brand-use checks apply?
  8. Strategic fitA strategic customer, market or segment—or an opportunistic request?
  9. Project riskWhat could make the project fail after we commit?

The pointThe objective was not to automate an approval flow. It was to turn dispersed commercial, technical, compliance and project judgement into a consistent, auditable decision model.

03Segmentation

How the reality was segmented

The dimensions produced a few classes. The class is set once at intake, can be raised when new facts appear, and decides everything that follows. OEM and private-label requests are not separate processes: they land in the class their consequences put them in.

FromEvery incoming RFI and RFQ

  1. RFIInformation only. Answered by sales and product management; no commitment, no gate.
  2. Standard RFQExisting references at known volumes. Commercial review within the price policy.
  3. Extended RFQVariants, new volumes or special requirements. Technical, quality and cost assessments before a price.
  4. Strategic projectNew development, investment or a strategic account. Full cross-functional assessment and a Go / No-Go gate.

Design decision

Classify requests by consequence—novelty, investment, capacity, risk, strategic weight—and let the class, not the salesperson or the amount alone, set the assessments, the decision owner and the clock.

04Target model

Target operating model

One governance lifecycle for every class. The class decides which steps are mandatory and who decides.

  1. Intake and classify
    Owner
    Commercial owner
    Exit criterion
    Request type, customer, class and required assessments recorded
  2. Assess
    Owner
    The functions the class requires
    Exit criterion
    Each assessment concluded: feasible, feasible with conditions, or not feasible
  3. Consolidate
    Owner
    Project lead (commercial owner for standard)
    Exit criterion
    One decision file: assessments, cost basis, risks, open conditions
  4. Go / No-Go
    Owner
    Decision owner of the class
    Exit criterion
    Decision recorded with evidence, conditions and rationale
  5. Offer
    Owner
    Commercial owner
    Exit criterion
    Offer issued within the decided conditions
  6. Award and handoff
    Owner
    Project lead
    Exit criterion
    Nomination recorded; development, validation and ramp-up milestones handed to the project

05What changes by path · Classification → assessments → decision rights

The class decides the judgement

Each class carries its assessments, its decision owner and a clock. The rights matrix makes explicit who decides, who approves and who is only consulted.

  1. RFI

    Information request, no binding offer

    Required assessments

    • Product fit
    Decision owner
    Sales
    Clock
    5 working days

  2. Standard RFQ

    Existing references, known volumes

    Required assessments

    • Commercial
    • Price policy
    Decision owner
    Sales manager
    Clock
    5 working days

  3. Extended RFQ

    Variant, new volumes or special requirements

    Required assessments

    • Commercial
    • Technical
    • Quality
    • Cost
    Decision owner
    Sales director
    Clock
    15 working days

  4. Strategic project

    New development, investment or strategic account

    Required assessments

    • Commercial
    • Technical
    • Industrial
    • Quality
    • Compliance
    • Financial
    • Strategic fit
    Decision owner
    Business leadership
    Clock
    Gate calendar

Who holds which right

D decides · A approves · R recommends · C consulted · I informed · — not involved
DecisionSalesEngineeringQualityPlantFinanceComplianceLeadership
Classify the requestDC————I
Technical feasibilityIDCC———
Industrial feasibility and capacityIC—DC——
Quality and validation planICDC———
Compliance clearanceI—C——D—
Cost basis and marginRC—CD—I
Go / No-Go, strategic classRCCCCCD
Offer conditionsD———A—I

D decides · A approves · R recommends · C consulted · I informed · — not involved

Classes, clocks and rights are illustrative. The pattern is the point: the class is set once, raised if the facts change, and every Go / No-Go leaves a decision record.

06Exceptions and return paths

The happy path is never the whole process.

When
WhenThenOwnerReturns to
New facts raise the class during assessment—new tooling, a new marketClass raised; the missing assessments are added and the clock restarts for the new classProject leadAssess
An assessment is overdueEscalated to the function’s manager when the clock runs out; the decision date is never moved silentlyAssessing functionAssess
Feasible with conditionsConditions recorded in the decision file and carried into the offer and the projectDecision ownerGo / No-Go
Two functions disagreeBoth conclusions stay in the file; the class decision owner decides and records whyDecision ownerGo / No-Go
No-GoRecorded with the reason and the gate; the customer is answered; similar requests can be found laterDecision ownerClosed, with a decision record
The customer asks for a price before the assessments closeNo binding price—an indicative range only, marked as suchSales managerAssess
The specification changes after the offerTreated as a new revision of the request; class and affected assessments re-checkedCommercial ownerIntake and classify

07Supporting capabilities and system encoding

Only now, the technology.

Systems and partiesCRMApproval engineDocument managementERPProject tooling

Supporting capabilities

  • CRMHolds the request, its class, the decision file and the outcome
  • Approval engineRoutes assessments and gates by class, and records who concluded what
  • Document managementKeeps drawings, specifications and assessment evidence with the request
  • Project toolingReceives the awarded project with its conditions and milestones
  • AI assistanceReads and structures incoming requests—see the AI-assisted RFQ case. It never classifies a consequential request on its own

How the system encodes the model

  1. Operating decision: Classes with different obligations

    System response: A class on the request; the required assessments are generated from it

  2. Operating decision: Assessments by function

    System response: One assessment record per function: conclusion, conditions, evidence

  3. Operating decision: Go / No-Go by a named owner

    System response: Gate decisions as records with approver, evidence and rationale—not a status value

  4. Operating decision: A clock per class

    System response: Service levels per class, with escalation on breach

  5. Operating decision: Conditions that must survive the offer

    System response: Conditions linked from the decision file into the offer and the project handoff

  6. Operating decision: Auditable decisions

    System response: Decision history per request, searchable across requests

08Measurement

What is measured—and what it triggers.

Metric
MetricWhyOwnerCadenceTriggers
Decision lead time by classShows whether each class’s clock is realisticCommercial operationsMonthlyRebalance assessment capacity or clocks
Assessments on time, by functionDelays hide in the functions that assessFunction headsMonthlyEscalate or resource the bottleneck
Go / No-Go ratio and reasonsShows what the company actually declines, and whyBusiness leadershipQuarterlyAdjust targeting and class criteria
Post-award surprisesTests whether the assessments caught the real risksProject managementQuarterlyStrengthen the assessment that missed
Class changes after intakeFrequent raises mean the class criteria are unclearCommercial operationsQuarterlyRefine the class criteria

09The second layer

Questions that change the design.

Classification

  1. Who classifies—and who may raise or lower the class?
  2. Is an RFI governed at all?
  3. What makes a request strategic rather than simply large?

Judgement

  1. Which assessments can run in parallel, and which depend on others?
  2. What does “feasible with conditions” oblige later?
  3. Who decides when two functions disagree?

Commitment

  1. When is a price binding?
  2. What does the project inherit from the decision file?
  3. How long does a Go decision stay valid if the customer is slow?

10Decisions & outputs

What the work produces.

  1. 01RFQ classification model
  2. 02Assessment catalogue by class
  3. 03Decision-rights matrix
  4. 04Go / No-Go gate and decision record
  5. 05Clocks and escalation rules
  6. 06Post-award handoff
Disciplines involvedProcess ArchitectureDigital Operating ModelRevenue OperationsAutomation