An AI purchase request intake agent accepts requests wherever employees already ask: a form, a shared mailbox or a message.
A form, email or chat message lands in the intake queue.
The agent reads the wording and any attached quote.
Free text becomes standard fields with source noted.
Low-confidence values are marked, not guessed.
The requester checks the summary and corrects it.
A complete record moves to the next step.
It writes the result into one consistent record, so a quote pasted into an email and a form entry look the same downstream. Anything it could not read with confidence is marked rather than guessed.
It then passes the record on to classification, policy checks and routing, and tells the requester it has been received. It does not approve or reject anything.
Intake is where most procurement friction starts, because requests arrive in every format and rarely contain everything a buyer needs.
Requests arrive by email, chat, hallway conversation and forms, so some never reach procurement at all.
A sentence such as 'we need a tool for design' hides the vendor, the term and the cost, so someone has to rebuild it by hand.
Quotes, order forms and screenshots hold the price and term, but nobody keys them into the record.
Without a shared record it is unclear who has seen a request and who is waiting on whom.
They chase by message, which adds interruptions for the procurement team.
The agent picks up the submission from each intake channel and logs the time, requester and original wording.
It extracts vendor name, quoted amount, term and quantity from any quote or order form attached.
Details are mapped to standard fields such as [vendor], [amount], [term], [department] and [business reason].
Fields it could not fill or was unsure about are flagged on the record for follow-up.
The requester gets a confirmation and the complete record moves to classification and policy checks.
Bring a small sample and watch Flo work through it.
| Aspect | By hand | With the agent |
|---|---|---|
| Entry points | Buyers watch the mailbox, chat and form separately and miss some requests. | One queue collects every channel with the original wording kept. |
| Attachment data | Quote figures are retyped by hand, or skipped. | Vendor, amount and term are read from the attachment and cited. |
| Record shape | Each requester describes the need differently, so records vary. | Every request lands in the same field layout. |
| Doubt handling | Unclear details are assumed or remembered informally. | Uncertain fields are marked on the record for a person. |
| Requester feedback | Requesters ask by message whether anyone has seen it. | An acknowledgement goes out on receipt with the captured summary. |
| If | Then | Who decides |
|---|---|---|
| Request arrives with a quote attached | Extract vendor, amount and term from the quote and cite the page | Buyer reviews the extracted values |
| Request names no vendor | Record the need as a category and mark vendor as open | Buyer decides whether sourcing is needed |
| Same text arrives through two channels | Link both to one record and note the second source | Requester is told only one request is live |
| Requester is not in the employee directory | Hold the record as unverified and tag the sender | Procurement operations confirms who they are |
| Attachment cannot be read | Store it unread and ask the requester for a readable copy | Requester resends |
| Request mentions urgency without a date | Mark the deadline field as unclear and keep the wording | Buyer confirms the real need-by date |
Each distinct item is split into its own record linked to the same source. The requester sees the split and can correct it.
The agent records both the sender and the stated beneficiary. Procurement operations decides which person owns the request.
Values are extracted as written with the currency noted, and no conversion is assumed. A buyer confirms the figures before they are used.
The record is created with only the stated need and is marked incomplete. The follow-up step asks the questions; the agent does not invent details.
Talk it through with the team. We will map it to your steps and show where a person stays in control.
Start with the form or the mailbox only, so the record layout settles before other channels join.
Let the agent build records alongside the buyers' own notes and compare field by field.
Bring in chat and quote reading once the first channel is trusted.
Keep a short log of corrected fields and adjust the field definitions each month.
A rising rate means the agent and the form are capturing what downstream steps need. A falling rate usually points to a new request type the intake does not yet cover.
Quick answers to what people ask most about purchase request intake.
Book a demoIt receives requests from different channels, reads the text and attachments, and builds one structured record. It marks anything unclear and passes the record on. It does not approve, reject or buy.
Yes, it can read free text from messages as well as form entries, as long as those channels are connected to the intake queue. Each is converted into the same record format.
The agent records what it can, flags the gaps and asks for the missing detail. A person reviews cases where the intent is still unclear.
No. It removes the retyping and chasing at the front of the process. Analysts still judge the need, apply policy and make the decisions.
Request classification is the step that labels an incoming purchase request by what it is: software, services, hardware, a renewal or a one-off buy.
→Request routing is the step that sends a purchase request to the right queue, team or owner once it has been captured.
→Intake form completion is the step where a purchase request form is filled in with the details procurement needs.
→Duplicate request detection is the step that spots when the same purchase has been asked for more than once, by one person or by several teams.
→Bring a small sample of real items. We will show what Flo handles on its own and where it hands over to your team.
