An AI request classification agent reads each new request and assigns a request type, such as new purchase, renewal, change to an existing contract or professional services engagement.
A structured request enters classification.
The agent reads description, vendor and amount.
It labels the request as software, goods, services or other.
The label is tested against the classification scheme.
A buyer confirms or changes any low-confidence label.
The confirmed class drives later routing and policy.
It adds risk tags drawn from your own rules, for instance handles personal data, needs a security look or involves an unusual term. These tags are suggestions that people can override.
The label is written to the record with a short reason, so a reviewer can see why the agent chose it and change it in seconds.
A request that is labelled wrongly goes down the wrong path, and nobody notices until a reviewer sends it back days later.
Two analysts can classify the same request differently, so routing becomes inconsistent.
Dropdown choices are made quickly and often reflect what the requester wants, not what the purchase is.
Without a link to existing records, a renewal is treated as a fresh purchase and skips the history.
A data-handling or security concern is noticed at contract stage rather than at the start.
Classification guidance lives in someone's head and changes without being written down.
It reads the description, the stated vendor and any attached quote or order form.
The request is compared against the request types and categories your team has defined.
It looks for an existing vendor or contract that suggests a renewal or amendment rather than a new buy.
Rule-based tags are added where the request mentions data, integrations or non-standard terms.
The label and a one-line rationale are saved, and low-confidence cases are marked for a person.
Bring a small sample and watch Flo work through it.
| Aspect | By hand | With the agent |
|---|---|---|
| Consistency | Two buyers label the same request in different ways. | One scheme is applied the same way to every request. |
| Speed | Classification waits until a buyer opens the request. | A proposed class is ready when the record arrives. |
| Reasoning | The label is chosen but the reason is not written down. | Each label carries the words in the request that supported it. |
| Hybrid requests | Mixed purchases get forced into one class, and checks are missed. | Mixed purchases are split or flagged for both paths. |
| Scheme drift | The scheme changes in people's heads, not in a record. | The scheme is a documented list the agent reads each time. |
| If | Then | Who decides |
|---|---|---|
| Request mentions a subscription or licence | Propose class software and flag the contract check | Buyer confirms the class |
| Request mentions hours, deliverables or a statement of work | Propose class services | Buyer confirms, since services often need a separate review |
| Request covers both hardware and software | Propose a split into two classes | Buyer decides whether to split the record |
| Wording fits no class in the scheme | Leave class empty and mark as unclassified | Procurement lead decides whether the scheme needs a new class |
| Vendor is already known in the vendor record | Use the vendor's usual class as supporting evidence | Buyer overrides if this purchase differs |
| Requester disagrees with the proposed class | Keep both views on the record | Buyer settles it and the choice is logged |
A managed service with bundled hardware fits two classes. The agent proposes the main class and notes the other; the buyer decides the split.
Nothing in the scheme matches, so the agent leaves the class open rather than forcing a fit. Procurement decides whether to add a class.
A vendor known for software may be selling consulting this time. The agent weighs the request text over the vendor's history.
Older requests keep their original class and new ones follow the revised scheme. A lead decides whether to relabel history.
Talk it through with the team. We will map it to your steps and show where a person stays in control.
Agree a short list of classes with plain definitions before the agent labels anything.
Run proposals next to buyer labels and record where they differ.
Let high-confidence labels pass without review while uncertain ones go to a buyer.
Use the override log to merge, split or rename classes quarterly.
A low rate suggests the categories and rules match how your team thinks. A high rate means definitions are unclear or a new request pattern is not covered.
Quick answers to what people ask most about request classification.
Book a demoIt is the labelling of a purchase request by type, category and risk so it follows the correct path. Done by hand it varies between people. An agent applies one set of written rules each time.
Your procurement team does. The agent applies the taxonomy and rules you set and can only be as consistent as those definitions.
It flags the request with its best guess and a reason, and leaves the decision to a person. Low-confidence labels are not applied silently.
Yes. If new information arrives, such as a different vendor or a larger scope, the request can be reclassified and its path adjusted by an analyst.
Purchase request intake is the step where a buying need first enters procurement, from a form, an email or a chat message.
→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.
