New requester onboarding concept

From business need to a decision-ready request

Learn what procurement needs at the first mile, then build a request and watch the route change as the commercial context changes.

For New internal requester
Time 8 min
By the end, you can Frame a complete request, understand how category, spend, supplier and risk signals affect routing, and know what happens after submission.

01 · The first-mile problem

A request can be urgent and still be impossible to act on.

Procurement does not need a longer email. It needs the few facts that determine who owns the request, which checks apply and what can happen next.

When those facts arrive across email, chat and attachments, the first step is reconstruction: What is being bought? How much? Is the supplier new? Is data involved? Which date actually matters? Every missing answer adds a clarification loop before the governed process has even started.

Key insight

Intake is a decision layer, not a form. Each answer should either improve the request or change the route.

02 · Request anatomy

Six signals turn intent into something the process can route.

The labels may differ by organization, but the logic is stable: capture the business context once, at the point where it can still prevent rework.

01Business need

The outcome, team and use case—not just the product name.

02Category

Software, services, hardware or another buying channel.

03Spend

Total commitment, currency and budget threshold.

04Supplier

New relationship or an existing supplier and contract.

05Risk

Data access, criticality and other review triggers.

06Timing

The business date and the consequence of missing it.

Requester tip

Write the need so that someone outside your team can understand the decision. “Keep product analytics live for Q4 planning” is more useful than “renew AnalyticsCo.”

03 · Interactive routing lab

Build the request. Watch the route respond.

Start with a worked renewal scenario, then change the inputs. The right side shows why a route appears—not just where the request goes.

New purchase requestIllustrative workflow
Draft requestKeep product analytics live for Q4 planning
Routing previewContract renewal path
5 signals captured
Why this route

What to notice: the requester supplies business facts; the intake layer translates them into ownership, checks and next steps. Routing logic shown here is illustrative and should be configured to the organization’s real policies.

04 · What happens next

Submission is a handoff, not a disappearance.

A useful requester experience answers three questions immediately: Did the request enter the process? Who owns the next move? What is blocking progress?

1IntakeStructured request
2ReviewRules and owners
3Source / contractRequired path
4DecisionVisible outcome
NowRequest received

The complete business context stays attached to the request.

NextProcurement owns triage

Budget, contract and risk reviewers are visible in the same flow.

If blockedOne action is named

The requester sees the missing evidence or decision—not a generic “pending.”

05 · Practical takeaway

Before you submit, run the 30-second test.

30sec
  • Need: Can a person outside my team understand the outcome?

  • Commercial context: Are spend, supplier and contract status explicit?

  • Risk: Have I said what the supplier or product can access?

  • Timing: Is there a real business date, not just “ASAP”?

Lesson completeA complete first mile gives automation something reliable to act on.