A custom procurement intake workflow should do more than collect a requester's name, budget, and preferred supplier. It should establish the facts that determine what happens next: what is being purchased, who will own the relationship, whether a supplier already exists, what risk review is required, and who has authority to approve the commitment.
When those facts arrive in a generic form and move through email, procurement inherits an incomplete decision. The team then spends its time chasing attachments, clarifying scope, and asking whether legal, security, finance, or the business owner has already reviewed the request. A well-designed intake workflow makes those questions answerable at the point of request - and keeps the answers connected to the supplier and agreement that follow.
Start with decisions, not a list of fields
Teams often begin by listing every field they could ask a requester to complete. That approach creates long forms, low-quality submissions, and unnecessary abandonment. Start instead with the decisions your team must make after a request is submitted.
For a software purchase, the first decisions may be whether an approved supplier is already available, whether the proposed vendor will process company or customer data, whether the purchase exceeds a delegated approval threshold, and whether a contract review is needed. For a consulting engagement, data handling may be less central, while insurance, statement-of-work terms, and budget ownership may matter more. The route should follow the facts of the engagement, not assumptions about its category.
The intake should collect only the information needed to route those decisions accurately. Additional questions can appear when an earlier answer makes them relevant. This is where custom workflows earn their value: one front door can support different purchasing categories without treating every request as identical.
A practical starting point is to map each intake type to four outcomes: the accountable business owner, the required assessment or review, the approval path, and the record that must be created or updated. If a request cannot produce those outcomes, the workflow is still gathering information rather than controlling the process.
Keep the business need separate from the supplier preference
A request has limited value when it sits alone in a queue. Procurement needs context that persists beyond the initial review. The strongest workflows connect the request to a supplier record, a contract record when one exists, and the accountable people responsible for the commercial relationship.
Every intake should establish a clear business need in plain language. Ask what outcome the requester needs, when it is needed, the expected term, estimated spend, and the cost center or budget owner. Those details help procurement distinguish an urgent operational dependency from a preference for a named vendor.
It also helps to separate “supplier requested” from “supplier selected.” A requester may have a preferred vendor, but that does not mean the organization has completed sourcing, due diligence, or commercial review. Labeling that distinction prevents a premature assumption that procurement is only there to process paperwork.
If there is an existing supplier, the intake process should surface that relationship rather than create a duplicate. The request can be linked to the supplier, its current agreements, known risk status, and upcoming renewal dates. A request for additional services may be an amendment, a renewal decision, or a new commercial commitment. Those are different paths with different controls.
Use conditional questions to collect the right evidence
Conditional logic keeps requesters focused while preserving governance. A new SaaS vendor that will access personal data can trigger questions about data categories, system access, hosting location, security documentation, and a security review. A low-value office services request should not require the same evidence.
Common routing conditions include spend level, category, supplier status, contract term, data access, geographic delivery, use of subcontractors, auto-renewal language, and whether the engagement involves regulated activities. The correct conditions depend on your policy and risk appetite. The objective is not to maximize questions. It is to collect sufficient evidence before the team makes a commitment.
Avoid a false sense of control created by too many mandatory fields. If a response will not influence routing, risk assessment, negotiation, approval, or the supplier record, it probably does not belong in the initial form. You can always request supporting detail within the review assigned to the right team.
Give every review an owner and a decision
Routing should not be a black box. Each person receiving a task should understand why they own it, what decision is expected, and what evidence is available. “Please review” is not a useful instruction for a security reviewer or finance approver.
For example, security may receive a task because the supplier will access customer data. Legal may receive a contract review because the vendor proposed its own terms. Finance may approve because total committed spend exceeds a threshold. The business owner may be asked to confirm that the scope and expected value are correct. Each action should be recorded against the request and remain visible as the supplier relationship develops.
Delegation-of-authority rules are particularly important here. Approval should follow the actual commitment value and the applicable entity and department rules, with the proposed term understood by the reviewer—not the sender’s memory of who usually signs. If an approver is unavailable, delegated authority should be explicit and auditable. A stalled request is often an ownership problem disguised as a workflow problem.
A custom workflow can also set service expectations without treating every request as urgent. High-risk requests may require staged assessments and longer review windows. A simple supplier extension may follow an abbreviated route. The workflow should make the trade-off visible: faster processing is appropriate when risk and commercial impact are lower, not because someone sends repeated follow-up emails.
Make assessment findings useful beyond intake
Supplier due diligence frequently breaks down after intake. Evidence is stored in a shared drive, assessment responses sit in a separate portal, and the approval record is buried in an email thread. At renewal, nobody can determine what was reviewed, what exceptions were accepted, or whether the supplier’s circumstances have changed.
Keep assessments connected to the intake context and supplier record. A privacy assessment, security questionnaire, financial review, or business continuity review should make its status, assigned owner, evidence, findings, and disposition clear. If a risk is accepted, record who accepted it, under what conditions, and whether a follow-up date applies.
This matters because an approval is rarely unconditional. Procurement leaders need to distinguish between “approved because no issue was found” and “approved with a documented exception.” The first supports routine management. The second requires follow-up before the next renewal, expansion, or contract amendment.
How this works in Fratera
Fratera supports this connected approach by keeping supplier records, agreements and standard approvals and e-signing in Core, with custom workflows and assessments in Pro SRM. Teams can configure forms, conditions and review steps around their process, and use assessment outcomes to carry relevant findings into the vendor or contract record. The operational advantage is straightforward: the team can see the decision and the evidence behind it without rebuilding the story from disconnected tools.
A practical example is Fratera’s “I need something” request. It asks for the need, details, business unit, estimated value and any supplier already in mind. In the example shown below, the answer to whether the supplier and price are known determines the next step. The purchase-request handoff presents the mapped purpose, unit and estimate, passes the supplier name into the search field, and retains the supporting answers for reference.
The person continuing the request still confirms the supplier, checks the prefilled information and completes the remaining fields in the normal purchase-request form. The intake submission does not itself approve the purchase or create a final commitment. That distinction matters: reusing information should remove repetition without removing accountability.
A handoff should preserve context, not just move the request
Intake is the beginning of procurement work, not a separate administrative stage. Once a request is ready to proceed, the process needs a clear handoff into the relevant purchasing, sourcing, contract review or onboarding work. The people, commercial assumptions, documents and reviews gathered at intake should remain available to the next owner. A handoff is not complete merely because somebody received a notification; it is complete when that person knows what to do and has the information to do it.
That handoff is especially important when negotiations change the commitment. If the final contract adds an auto-renewal clause, increases the term, changes data processing or exceeds the originally approved value, the responsible owner should check whether legal, security or an additional approver must review it again. Build that comparison into the process and make the responsibility explicit. Approval of an estimate is not necessarily approval of the executed agreement.
After signature, assign an accountable supplier owner and contract owner. Capture notice periods, renewal dates, obligations, and review milestones. A request that ends at signature leaves the organization exposed to the next avoidable problem: discovering an exit window after it has closed.
Test the awkward cases before rollout
Before rolling out a new intake process, test it with a small set of realistic scenarios. Use a new high-risk software vendor, an existing supplier renewal, a low-value services purchase, and an urgent business-critical request. These cases reveal whether conditions, ownership, and escalation rules work as intended.
Look for requests that route to nobody, requests that require the same information twice, and approvals that occur before the reviewer has the relevant evidence. Also look for the opposite failure: a low-risk request taking the full enterprise review path. Consistency does not mean every request receives the same treatment. It means comparable risk and commitment receive comparable control.
Review the process after launch. Useful measures include time spent waiting for requester information, review-cycle duration by function, reassignment rates, exception volume, and requests that return for reapproval. Use the records and reporting available to your team to establish a baseline. Those patterns show whether the problem is form design, unclear policy, overloaded reviewers, or missing supplier data.
From processing requests to managing commitments
A good intake workflow gives procurement an earlier point of control without becoming a barrier to the business. It makes the next decision clear, assigns it to an accountable owner, and preserves the evidence needed when the supplier relationship is reviewed again. That is how teams move from processing requests to managing commitments before deadlines and risk exposures dictate the outcome.
Watch the request keep its context
Follow a request from its first answers through a conditional handoff into a prefilled purchase-request form, then add a clear review instruction before proceeding to approval.
Read the video walkthrough
Enter a business need for workspace licences. Complete the intake details, unit, estimate and preferred supplier, and confirm that the supplier and price are known. Submit the intake and see the branch choose “Continue as purchase request.” The handoff shows the purpose, unit and estimate filled from the answers, with original supporting detail retained. Open the next form: the carried-forward information is ready to check, while supplier selection and the remaining fields still need human attention. Add an instruction to confirm security review before approval. Good intake gives the next decision an owner and context.
Procurement workflows in Fratera