Skip to main content
Request path

AI intake for procurement

Every purchase starts with one conversation.

Give employees one place to ask, buy, and see what happens next. Turn a plain-language request into a structured record with a visible policy route.

Synthetic company, policy, and request. No document is uploaded here. Trial requests are reviewed; if the case fits, we agree the bounded scope before any data is shared.

Procurement assistantSample interface
Hi Riley, what do you need help with?

We need a research tool for the design team.

Guide me through a request Ask about policy Check request status
Request understood
Budget ownerSecurityProcurement
Proposed route from fictional policy PROC-v4.2

Sample interface

Start with the request. Reveal the path.

The requester gets a short conversation. Procurement gets the structured record and policy basis needed to move it forward.

New purchase request Fictional company · Sample interface
Sample route is ready Applying sample policy Route explained
Requester view

Tell us what you need

Synthetic conversation
Sample requester

We need a research tool for the design team before the next planning cycle.

Intake

Will the tool receive company or customer data?

Company dataCustomer dataNeither
Sample requester

Company research notes, but no customer records.

Adaptive follow-up

Which team budget will cover it, and is there an existing tool that overlaps?

Reply to the intake question
Structured request

Research software

Intake complete
Purpose
Design research and synthesis
Requester
Sample design lead
Data
Internal company notes
Timing
Before the next planning cycle
Budget owner
Design operations
Vendor state
New supplier
Overlap check needs an owner

Fictional PROC-v4.2, clause 3.3 requires a preferred-tool overlap check before approval.

Policy route

Why this request goes here

Proposed path
  1. Intake capturedPurpose, owner, timing, vendor, and data use recorded
    Complete
  2. Budget ownerPROC-v4.2, clause 2.1: committed spend needs funding approval
    Next
  3. Security reviewPROC-v4.2, clause 4.2: internal company data triggers review
    Queued
  4. Procurement checkPROC-v4.2, clause 3.3: new supplier and overlap check
    Queued
  5. Decision and handoffRequester sees the outcome, conditions, and purchasing next step
    Pending
Route rationale

Internal data triggers security review. A new supplier triggers procurement review. The sample request does not indicate customer data, so privacy review is not added.

Controls are inactive in this local sample interface.

Every person, company, request detail, policy condition, reviewer, and status in this interface is synthetic.

One request, two useful views

Simple for the employee. Structured for the team.

REQUESTER

Ask in familiar words

The conversation follows the request and asks only the next relevant question.

PROCUREMENT

Receive a complete record

Purpose, spend context, data use, vendor state, and missing fields arrive in a consistent shape.

APPROVERS

See why review is required

Every stop shows the policy condition, current owner, state, and next handoff.

Route design

Add review because the request requires it.

The proposed route exposes the reason for every branch. Complex requests can take a deeper path. Routine requests should not inherit irrelevant steps.

What does the request touch?
Company data Security Review storage and access
Customer data Privacy Review use and handling
New supplier Procurement Check terms and overlap
Committed spend Budget owner Confirm funding authority

Fictional PROC-v4.2 logic only. A work trial would use the organization’s approved policy and authority map.

One bounded work trial

Run one request through your policy.

Bring one low-to-medium-risk request type, the approved policy, and the approver map. A person reviews each application. Applying does not guarantee access, and no document is uploaded from this page.

Request a routing trial Opens the reviewed Praxis trial application

Free operating resource

Procurement intake form template

Make core fields required, then reveal conditional questions by purchase type and risk. Connect each answer to the current policy route, named approvers, and a visible decision state.

Open the guide and fictional template

Take the sample apart

Compare the untouched packet with the review copy.

These files are fictional and safe to inspect. They show the exact export and source trail a trial would need to produce.

Inspectable sample run

See the request, rule, approver, and next move.

Every field below belongs to the fictional sample shown on this page. It shows the output we would evaluate in a bounded trial; it is not a customer result.

Source input
A fictional SaaS renewal, procurement policy PROC-v4.2, approver map, and duplicate-tool record.
Applied rule
Value, data access, renewal timing, and overlap determine required intake and parallel reviewers.
Resulting state
The request returns for four missing fields before budget, IT, security, privacy, and procurement review.
Human checkpoint
Authorized reviewers supply each decision; the sample route never represents their approval.
Sample receipt
PROCURE-EX-20260904, fictional route, no purchase or approval recorded.
Freshness
Fictional sample v2, updated 2026-09-04.