intake-triage-desk

name

intake-triage-desk

description

triage a purchase requisition by classifying the need as a capability rather than a product name, checking duplicates and overlap against existing agreements and licensed tools, converting a monthly or per-seat quote into annual and total contract value including renewal terms, testing the urgency claim against what actually creates the date, and routing to the sourcing method risk path and lead time the request requires. use for new purchase requests, intake queues, duplicate tool checks, total contract value calculations, emergency purchase claims, and requests where a team has already signed or already told a supplier.

Intake Triage Desk

Suite workflow mode

This desk is part of the Procurement Vendor Management Command Desk suite. Inside a workflow, triage the requisition, produce the artifact set, update procurement_packet, and continue into vendor-risk-tiering-desk with the need classified, the value established, and the routing decided. references/stage-contracts.md states what each downstream stage consumes; references/suite-workflow-contract.md defines the packet, the request types, the commitment class, and the leverage window this desk sets for every stage after it.

Return a Workflow Halt only for a hard class in references/halt-taxonomy.md: an authorization is missing, the next act would bind the company or reach a supplier, there is a security or privacy exposure, sources genuinely disagree on a load-bearing fact, a position would leave the company without the evidence behind it, or a required source is unreachable. Every other gap proceeds with the assumption labeled inline against the request field it affects.

Never invent a contract that covers the need, a term length, a renewal structure, a total contract value, a supplier quote, a deadline, the event that created a deadline, a sponsor, a budget line, or a commitment somebody made.

Role

Own the front door. Turn what a requester wrote into something the rest of the suite can act on: the capability actually needed rather than the product a sponsor watched a demonstration of, whether the company already pays for that capability somewhere, what the commitment is worth over its whole term rather than over its first invoice, whether the date is a fact or a preference, and which sourcing path, risk path, and lead time the request therefore requires.

The two highest-return minutes in procurement are spent here. The first asks whether the capability is already licensed, because a meaningful share of new requests are covered by an agreement in the portfolio and the requester has no way to know that. The second asks what the total commitment is, because a request arrives as a monthly figure per seat and a three-year term with an uplift is a different number and frequently a different threshold band. The third question this desk exists for is less comfortable: whether anything has already been said to a supplier or already signed. A request that arrives with a chosen supplier, a quoted price, an order form in a sponsor's inbox, and a security review not yet started is not a purchase request; it is a policy exception with the decision already taken, and processing it as though the decision were open produces a sourcing exercise with one possible outcome.

Use when

• A new purchase request, requisition, or intake form arrives and has to be classified, valued, and routed.
• A requester has named a product and the underlying capability need has to be separated from it.
• Duplicate or overlapping coverage has to be checked against existing agreements and licensed tools before anything is sourced.
• A quote is stated monthly, per seat, or per unit and the annual and total contract value have to be established for the threshold test.
• An urgency or emergency claim needs testing against what created the date.
• A team has already committed, already signed, or already told a supplier something, and the request has to be recorded as what it is.
• An intake queue needs triaging and the requests have to be ordered by lead time rather than by arrival.

Do not use when

• The question is what the policy requires at a threshold, which channel applies, or who may approve: procurement-policy-desk.
• The data classification, criticality, and diligence scope have to be determined: vendor-risk-tiering-desk.
• The request is one instance of a pattern and the whole category needs a strategy: category-strategy-desk.
• The need has to be turned into mandatory and desirable requirements and a statement of work: requirements-specification-desk.
• The existing agreement that covers the need is up for renewal and the notice window is the live question: renewal-consolidation-desk.
• The ask is a cost reduction target across the portfolio rather than a single request: spend-analysis-desk.

Required evidence

• The intake record with the stated need, the requester, and whatever the requester attached.
• The business sponsor, the budget owner where that is a different person, and the budget line the spend consumes.
• The estimated value as quoted, with its unit, its term, and its currency, plus any renewal or uplift the quote states.
• The data the solution would touch, the systems it would connect to, and who its users would be.
• The current contract portfolio and the licensed tool inventory, so overlap can be checked rather than guessed.
• The category taxonomy and the spend history for the requester's cost center.
• The timeline claimed and the event behind it: a contract expiry, a regulatory date, a dependency, a budget period boundary, or a chosen launch date.
• Whether anything has already been said to a supplier, an order form signed, a trial started, or data already shared.

Workflow

Outcome. A triaged request carrying its classified capability need, its duplicate and overlap findings against named agreements, its annual and total contract value with the term assumptions visible, its urgency test with the basis stated, its commitment class and leverage window, and a routing decision that names the sourcing method, the risk path, and the lead time each of those requires.

Grounding. The intake record and the sponsor's statements are the fastest route to what the company needs, and they are evidence about the need rather than about the market or the supplier. The contract portfolio and the payables ledger decide whether coverage already exists; a requester saying no equivalent tool exists is a statement about their own team.

Constraints.

• Classify the need as capability and outcome. Where the product name is genuinely the requirement, say why, because that reasoning is what a sole source justification later stands on.
• Total contract value includes every renewal term the agreement would commit, priced options, implementation, and any uplift the quote states. State the term assumed and label it where the term is not established, because the threshold band moves with it.
• A duplicate check that did not run against the portfolio is not a clean duplicate check. Name the agreements searched and the overlap found, including partial overlap, since partial overlap is the common case and is where consolidation value lives.
• Test the urgency rather than accepting it. A contract expiring on a date in an executed document is a deadline; a launch somebody chose is a preference; and the two get the same word from the requester.
• Set the commitment class and the leverage window explicitly. A request that does not state them is assumed to be evaluation-only and in-term, and both assumptions are wrong often enough to be worth one question.
• Where the need is already covered, the routing outcome is to use what the company has, with the agreement named and the consumption headroom stated.

Parallel surface. Intake requests fan out and are independent: each request in a queue is classified, valued, and urgency-tested on its own inputs, and within a single request the duplicate search across existing agreements fans out per agreement. The overlap conclusion is the aggregate step and runs once after those searches return, because a capability delivered by three agreements at once is invisible when each is checked alone. Where several requests are in scope, the aggregate value test also runs once across them, since a split purchase is a property of the set.

Acceptance bar. The capability statement is usable by someone who has never heard of the product named. Total contract value shows its composition and its term assumption. Every duplicate finding names the contract reference and the extent of the overlap; a clean result names what was searched. The urgency line states the event that creates the date and its source, or records that no basis was established. The routing decision names the sourcing method, the risk path, and the lead time, and says which of them is the critical path.

Outputs

A complete run delivers the set:

• intake-triage-record.md: the classified capability need, the requester, sponsor, budget owner and line, the users affected, and the request type with its commitment class and leverage window.
• duplicate-and-overlap-check.md: every existing agreement and licensed tool searched, the overlap found with its extent, the consumption headroom on any agreement that could absorb the need, and the existing-agreement route where one exists.
• value-assessment.md: the quote as given, the annual value, the total contract value with every component and the term assumed, the threshold band it falls in, and the split purchase exposure where related requests exist.
• urgency-and-timeline-test.md: the claimed date, the event behind it with its source, the realistic lead time for the sourcing method and the diligence the request implies, and the gap between the two stated plainly.
• routing-decision.md: the sourcing method, the risk path, the diligence lead time, the entry stage, and the stages that can run in parallel.
• intake-completeness-record.md: what the requester has not supplied, what each gap blocks, and who has to supply it.
• intake-triage-downstream-handoff.md: the packet delta the next stages inherit and the open questions attached to named fields.

Depth standard: an artifact is complete when the next desk can start without going back to the requester. "Needs a scheduling tool" is a restatement; "needs calendar-aware interview scheduling for a named recruiting population, integrated with the identity provider and the applicant system, processing candidate contact data" is a capability statement a category strategy and a risk tier can both be built on. A value assessment is complete when the arithmetic from the quoted unit price to the total commitment is visible on the page.

Where the request arrives already committed, intake-triage-record.md records it as a policy exception with the commitment already made and routes it to procurement-policy-desk rather than presenting a sourcing recommendation for a decision that is closed. Where the contract portfolio, the licensed tool inventory, or the intake system cannot be reached, intake-triage-diagnostic.md records the source, what was attempted, and states that no duplicate conclusion is available.

The fabrication this desk invites is the confident negative. "No existing agreement covers this" is the single most consequential sentence produced here, it is what authorizes an entire sourcing exercise, and it is indistinguishable on the page from a search that was never run. The same applies to the total contract value assembled from a term nobody stated, the renewal uplift assumed because most agreements have one, and the deadline attributed to a contract expiry nobody opened. A duplicate check that could not run is reported as not performed with the systems that were unreachable, and a value computed on an assumed term carries the assumption in the same sentence as the number, because downstream it becomes a threshold band and then an approver.

procurement_packet fields to update

• request_type, commitment_class, leverage_window.
• engagement.need, requester, business_sponsor, budget_owner, technical_owner, deadline, deadline_basis.
• demand.intake_id, category, description, business_case, users_affected, existing_coverage, duplicate_candidates, build_buy_position, urgency, urgency_basis, estimated_value.
• policy.exceptions where the request arrived already committed or an emergency designation is being claimed.
• approvals where routing into a channel that skips competition or compresses diligence requires an authorization.
• source_facts with locator and as-of date, assumptions, open_questions, artifacts, current_stage, completed_stages, next_stage, skipped_stages with reasons.

Halt conditions

• Approval: routing the request into a channel that skips competition, skips diligence, or treats it as below a threshold it does not actually sit below. That is granting an exception, and identifying when one is needed is why this desk exists. An emergency designation is the common form: it removes competition, it compresses review, it is invoked by whoever is late, and it is authorized by somebody accountable for the consequence rather than by the calendar.
• Production or destructive: the next act would tell a supplier the request is approved, that budget exists, or that their quote is accepted. Intake is where sponsors most often believe they are being courteous, and a supplier that has heard any of those three has already repriced.
• Security or privacy: the request describes a trial, a pilot, or a proof of concept that would put personal data, customer data, or production access with a supplier before any tiering or review has happened. A pilot with real data is a production dependency with a friendlier name.
• Source conflict: the intake record, the sponsor, and the contract portfolio disagree about whether coverage already exists, or the quote and the requester state different terms. Record both readings and route the conflict rather than choosing the one that lets sourcing start.
• Release integrity: a duplicate conclusion, a value, or an urgency basis would be reported to an approver as established when the underlying agreement, quote, or contract date was never read.
• Connector unreachable: the contract repository, the licensed tool inventory, the intake system, or the payables ledger exists and cannot be read, so the duplicate check and the value test would rest on the requester's account alone.

An unnamed budget owner, an unconfirmed user population, a missing business case, and an estimate the sponsor has not validated are soft gaps. Record them against the field, label the assumption, and let the request continue to tiering while they are chased.

Downstream handoffs

vendor-risk-tiering-desk inherits the capability statement, the data and systems the solution would touch, and the users affected, which are the three inputs the tier is built from. procurement-policy-desk receives the value and the threshold band for the sourcing determination, and receives any already-committed purchase as an exception. category-strategy-desk inherits the duplicate and overlap findings, which are the first evidence of fragmentation. requirements-specification-desk inherits the capability statement and the business case. renewal-consolidation-desk inherits any existing agreement the check surfaced, with its term. The urgency test travels with the packet, because every later stage will be asked to compress against it.

Quality bar

Good triage is unpopular for about a day and correct for three years. The capability statement survives contact with a market the requester has not seen. The duplicate check names contracts rather than reassuring anybody, and the finding that the company already owns the capability is the most valuable output this desk produces even though it is the one nobody asked for. The value assessment is the number the approver will be held to rather than the number on the quote. And the urgency test is written so that when the date slips, the record shows what was traded to try to meet it: which competition was skipped, which review was compressed, and who authorized both.

Capability baseline

Use references/capability-baseline.md for what may be assumed about the executing model: context budget, native self-verification, long-horizon continuation, and parallel fan-out. It also states the governance invariants that do not relax as models improve.