An AI request routing agent reads the structured request and compares it with your routing rules, for example which team handles software, which handles facilities and who owns a given budget.
A labelled request reaches routing.
The agent reads who handles which type and size.
It picks the queue and the named handler.
It notes absence or a full queue.
A lead settles any request with no clear owner.
The handler is notified and the requester sees who has it.
It places the request in the correct queue and notifies the owner, adding a short note on why that destination was chosen.
When two rules conflict or none applies, it does not pick one. It parks the request for a procurement lead to direct.
Routing looks simple, but small errors send requests to the wrong desk, where they sit until someone notices.
A misrouted request waits in a queue nobody is watching, and the requester assumes it is moving.
Who handles what is often known only by a few people, so cover during absence is patchy.
A request can legitimately belong to IT and to finance, and nobody is sure who goes first.
Analysts forward requests by email, which leaves no record of why it went where it did.
When a team lead leaves, requests keep flowing to a person who is no longer there.
The agent takes the category, amount, department and tags from the structured request.
It looks for the rule that fits, such as software over a set value going to the IT sourcing queue.
It checks the destination owner's status, including out-of-office and delegation settings.
The request is placed in the queue, the owner is notified and the reason is logged.
Requests with no matching or with conflicting rules are held and flagged for a lead.
Bring a small sample and watch Flo work through it.
| Aspect | By hand | With the agent |
|---|---|---|
| Ownership | Requests sit in a shared inbox until someone claims them. | Each request is offered to a named handler or queue on arrival. |
| Rule upkeep | Routing knowledge lives in a few people's memory. | Routing rules are written down and read each time. |
| Absences | Requests wait for a handler who is on leave. | Leave and cover are read from the routing map. |
| Misroutes | A wrong team receives it and forwards it, losing days. | The reason for each route is recorded so errors can be traced. |
| Requester view | Requesters do not know who is handling their request. | The requester is told the handler's name or team. |
| If | Then | Who decides |
|---|---|---|
| Request is software and above the security review line | Route to the security-reviewed software queue | Security lead owns that queue |
| Request is a repeat purchase from a known vendor | Route to the renewals handler | Buyer who owns the vendor decides next steps |
| Request is for a department with a dedicated buyer | Route to that buyer | Procurement lead maintains the mapping |
| Named handler is marked absent | Route to the listed cover and note why | Cover handler accepts or reassigns |
| Two routing rules match with different owners | Hold the request and show both rules | Procurement lead picks the owner |
| No routing rule matches | Send to the general queue with an unmatched flag | Procurement lead decides if a rule is missing |
Two valid rules point to different handlers, so the agent will not pick one. It holds the request and shows both rules to a lead.
Open requests are re-offered to the cover named in the map. The cover decides whether to keep or pass them on.
The agent re-reads the map and proposes a new route with the reason. The current handler confirms the move.
Urgency stated by the requester is shown to the handler but does not jump the queue by itself. The handler or lead decides priority.
Talk it through with the team. We will map it to your steps and show where a person stays in control.
Record who handles what for one department or class before the agent routes anything.
The agent proposes the owner and a person clicks to assign.
Allow direct assignment for rules that have never been overridden.
Review misroutes each month and update owners after team changes.
It shows how often the destination was right without a redirect. A dip often follows an organisation change that the rules have not caught up with.
Quick answers to what people ask most about request routing.
Book a demoIt sends each purchase request to the right queue or owner according to your written rules, records why, and holds anything that fits no rule for a person to direct.
Request routing decides which team handles the request. Approval routing decides who must approve it. They use different rules, though the second often follows the first.
The agent can use the delegation or backup you have defined for that owner. If none is set, it flags the request to a lead rather than leaving it waiting.
Yes. Any authorised person can redirect a request. The change and the reason are logged so the rules can be improved.
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.
→Intake form completion is the step where a purchase request form is filled in with the details procurement needs.
→Purchase request intake is the step where a buying need first enters procurement, from a form, an email or a chat message.
→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.
