Free operational template ยท Procurement intake and approval routing
Procurement intake form template
This intake form turns a purchase request into a routeable decision. It collects the business need, requested outcome, supplier, cost basis, timing, data and system access, contract conditions, risk, and required approvers. Use it for new purchases, renewals, software, services, and equipment after tailoring the paths to company policy. The form should shorten the route for ordinary requests while exposing exceptions early. It does not approve the purchase.
Use it when
The work has a live owner and finish line.
- An employee requests software, services, equipment, a new supplier, or a renewal and needs the authorized path.
- Procurement repeatedly returns requests because the business need, owner, cost, data use, or deadline is missing.
- Security, privacy, legal, finance, and procurement need different questions based on purchase type and risk.
Do not use it when
The template would hide missing authority.
- Do not treat form completion as budget, legal, security, privacy, supplier, or purchase approval.
- Do not collect bank details, credentials, sensitive personal data, or confidential supplier material unless the approved system and reviewers require it.
- Do not use one fixed workflow when policy provides different routes for renewals, low-risk purchases, regulated data, or emergency requests.
The working fields
Every column has a job.
Keep the source, decision, and owner visible. Replace the fictional values with approved information from your own process.
| Field | What to record | Fictional example |
|---|---|---|
| Requester and business owner | Name the person submitting and the leader accountable for the need, budget, adoption, and resulting supplier relationship. | Requester: Morgan Ellis; business owner: VP Operations |
| Purchase type | Select new purchase, renewal, expansion, replacement, trial, service, software, equipment, or another policy-defined class. | New software subscription |
| Business need and outcome | Describe the current problem, who is affected, and the observable outcome. Avoid a feature list copied from the supplier. | Route facilities requests to the on-call team with an auditable owner |
| Requested scope | Record users, teams, locations, quantity, term, environment, services, implementation, and exclusions known today. | Thirty operations users for a twelve-month term; no external customer access |
| Supplier and alternatives | Name the proposed supplier, selection status, alternatives considered, existing contracts, and reason a new purchase is needed. | Fictional Acorn Route; existing ticket system lacks approved on-call routing |
| Cost basis and budget owner | Capture quoted currency, one-time and recurring components, term, assumptions, budget code, and approving owner. Do not calculate undisclosed commitments. | Fictional quote of USD 24,000 annually plus implementation, pending finance review |
| Need-by date and consequence | State the real decision or use date, why it matters, and whether the supplier imposed an expiration. Separate urgency from pressure. | Decision by October 1 for planned winter operations training |
| Data and access | Identify data categories, personal or regulated data, systems, integrations, credentials, regions, retention, deletion, and subcontractor questions. | Employee names and work contact details; no payment or health data planned |
| Security and privacy route | Apply current policy triggers and name reviewers. Do not ask the requester to self-certify risk they cannot assess. | Security review required because software receives employee data |
| Legal and commercial route | Record contract type, supplier paper, term, renewal, termination, insurance, intellectual property, service levels, and deviations requiring review. | Supplier terms with automatic renewal; legal owner assigned |
| Operational and supplier risk | Capture criticality, replacement options, implementation owner, support model, continuity, accessibility, and concentration concerns. | Medium operational criticality; manual fallback documented |
| Approvals and decision state | List required approvers, sequence or parallel route, current state, conditions, final decision, and receipt. | Pending security and budget review; no purchase authorization issued |
Worked example
Fictional example: Acorn Route request
A fictional operations team requests Acorn Route, a fictional scheduling service, for thirty employees. The supplier quote is available, but the request says only needed urgently. The service will receive employee names and work contact details, and the contract includes automatic renewal.
- Business need and outcome
- Route facilities requests to a named on-call owner and preserve assignment history.
- Requested scope
- Thirty internal users, one year, no external customer access.
- Cost basis and budget owner
- Fictional USD 24,000 annual quote plus implementation; budget approval pending.
- Need-by date and consequence
- Decision by October 1 to complete winter operations training.
- Data and access
- Employee names and work contact details; system integrations not yet approved.
- Approvals and decision state
- Route to procurement, security, privacy, legal, and budget owner. Request remains under review.
The request receives a defined route and owners. It is not approved merely because all fields are complete. The example, supplier, amount, and dates are fictional and demonstrate form behavior rather than a procurement outcome.
Operating rules
Rules that preserve the real work.
- Form completion is intake, not approval.
- Ask for the business outcome before supplier features.
- Route from current policy and facts, not from requester confidence.
- Use conditional questions so low-risk requests do not carry every high-risk field.
- Preserve decisions, conditions, approvers, and receipts with the request.
Failure modes
Where a useful template turns misleading.
- The form begins with vendor name
Capture the need, user, outcome, owner, and alternatives before allowing the supplier choice to frame the decision.
- Every request follows the longest path
Define policy-based branches by type, amount, data, access, criticality, term, and exception.
- Sensitive data enters free text
State what not to submit, use approved uploads where needed, and collect categories rather than payloads.
- Approval disappears into email
Write the decision, conditions, approver, time, and source back to the intake record.
Put it to work
Adopt it in four controlled moves.
- 01
Map current authority
List purchase classes, thresholds, policy triggers, approvers, review order, exceptions, and the system that holds the final decision.
- 02
Design core and conditional fields
Require the common business facts, then show security, privacy, legal, finance, or supplier questions only when the request triggers them.
- 03
Test real request shapes
Run a renewal, low-risk purchase, professional service, data-bearing software, equipment request, and policy exception through the draft route.
- 04
Publish service expectations
Tell requesters what happens next, which owner has the request, what is missing, and what approval means. Review routing errors and update policy links.
Questions teams ask
Before the template enters a live workflow.
Which fields should always be required?
Usually requester, business owner, purchase type, business need, scope, supplier status, cost basis, need-by date, data and access categories, and a policy route. Your policy decides the final set.
Should security review every request?
Use current risk and procurement policy. A conditional route can involve security when data, system access, criticality, software, or supplier conditions trigger review without forcing identical work on every purchase.
How should renewals differ from new purchases?
Carry forward the current contract and ownership, then ask what changed: scope, users, price, term, data, incidents, performance, alternatives, and business need. A renewal is a new decision, not a silent continuation.
Can intake routing make the approval decision?
It can identify the likely path and missing inputs. Only people or systems with documented authority should approve, reject, or condition a purchase.
Sources and boundary
Category context, not borrowed proof.
Sources reviewed 2026-09-04. Vendor pages describe category expectations and are not independent validation of performance.
- NIST Cybersecurity Supply Chain Risk Management
Public resources for identifying, assessing, and mitigating cybersecurity supply-chain risk across acquisition and the system life cycle.
- NIST Manufacturing Extension Partnership supply chain guidance
Public overview of supplier evaluation, total cost of ownership, risk assessment, and procurement strategy.
- Levelpath intake orchestration
Vendor description of procurement intake and orchestration, included as category context.
Use boundaryThis form supports intake and routing. It does not approve spending, select a supplier, interpret policy, authorize data access, or replace procurement, finance, security, privacy, legal, accessibility, compliance, and business-owner review. Tailor it to current authority and applicable law.
Research connection: Aligned asks when generated output should count as accountable work. This resource applies that question to procurement intake and approval routing.
One bounded case
Route one request through visible policy
Bring one sanitized purchase request, the applicable policy clauses, and the authorized review owners. Praxis can return a purchase path brief with missing inputs, conditions, and decision receipts in a bounded supervised trial. Applications are reviewed and do not guarantee access.
Request a procurement trial