An AI request status tracking agent reads the live state of each request, including its current stage, owner, last action and any open questions, and keeps that picture up to date.
A requester wants to know where their request is.
The agent reads stage, owner and open items.
It states the stage and what happens next.
If waiting on someone, it names who.
Buyers add notes the record cannot show.
The query and answer are saved.
When a requester asks where their request is, it replies with the stage, who holds it and what is awaited, in plain words.
It watches for requests with no movement and tells the relevant owner or procurement lead, so stalled items are noticed early.
When status is hidden, requesters chase by message, and every chase interrupts someone who could be doing review work.
Only the person holding the request knows its position, so everyone asks them.
Staff change a stage and forget to tell the requester.
A request sitting with an approver looks identical to one being actively worked.
The same where-is-my-request message arrives several times a day.
A request stuck for weeks is noticed only when the requester complains.
The agent reads stage changes, assignments and comments as they are recorded.
It records the current stage, owner, last activity time and anything the request is waiting for.
Requesters can ask in chat or email and receive a plain summary with the next expected step.
It sends a note when a request changes stage or when a question is waiting on the requester.
Requests with no activity beyond your set period are surfaced to the owner or a lead.
Bring a small sample and watch Flo work through it.
| Aspect | By hand | With the agent |
|---|---|---|
| Status checks | Requesters email buyers to ask where things stand. | Requesters get the current stage and owner on request. |
| Accuracy | Answers come from memory and are sometimes wrong. | Answers come only from the live record. |
| Blockers | Nobody can say who a request is waiting on. | The agent names the pending person or step. |
| Buyer interruptions | Status questions break buyers' focus. | Routine questions are handled without buyer time. |
| Proactive notice | Requesters learn of a rejection late. | Stage changes can be posted to the requester as they happen. |
| If | Then | Who decides |
|---|---|---|
| Request is awaiting an approver | State the approver and how long it has waited | Approver is not contacted unless a reminder rule applies |
| Request is waiting on the requester | Say what is needed and offer to resend the question | Requester provides it |
| Request is in a policy check with a failure | Explain the finding in plain words | Buyer discusses the way forward |
| Request was rejected | Show the recorded reason and next options | Approver or buyer explains further |
| Status asks for a delivery date not in the record | Say that it is not recorded | Buyer confirms with the vendor |
| Requester asks to prioritise | Log the request for a buyer and say so | Buyer decides priority |
The latest update has not been entered, so the answer could be wrong. The agent shows the last update time, and the buyer corrects the record.
A colleague asks about a request they did not raise. The agent shares only what the access rules allow, and the buyer decides on more.
The agent explains each related record and its stage. The buyer clarifies how they relate.
A request under review for a vendor issue may not be shared fully. The agent gives a neutral stage and refers details to a buyer.
Talk it through with the team. We will map it to your steps and show where a person stays in control.
Begin with stage and owner questions only.
Have buyers compare answers with the real state for a few weeks.
Offer proactive stage notices to requesters who ask for them.
Use frequent questions to improve what the record captures.
A falling number suggests requesters can see progress without asking. A rise may mean notifications are not reaching them or stage names are unclear.
Quick answers to what people ask most about request status tracking.
Book a demoIt follows each purchase request through its stages, tells requesters where it stands and who holds it, and alerts people when a request has stopped moving.
It reports the current stage and what is awaited. It should not promise a decision date, as approvers decide in their own time.
You choose what is shared. Stage, owner and what is awaited are usually fine, while internal notes can be kept from view.
It compares time since the last activity with the period your team sets for that stage, then flags the item to the owner or a lead.
Requisition creation is the step that turns an approved purchase request into a formal requisition with line items, coding and vendor details.
→Request SLA monitoring is the step of tracking how long each purchase request spends in each stage against the service targets your team has set.
→An existing contract check is the step that asks whether a vendor already has an agreement with your company before a new purchase goes ahead.
→Request escalation is the step that raises a purchase request to a more senior or different person when it stalls, breaches a rule or carries unusual risk.
→Bring a small sample of real items. We will show what Flo handles on its own and where it hands over to your team.
