Purchase request intake
Most bad purchase requests are not bad, they are incomplete: no owner, no threshold check, no idea whether the organisation already buys this. This agent takes the request in the channel where people ask, retrieves the policy and any existing agreement, and routes a complete request to the named approver. The approver decides.
Step by step
Take the request in the channel
Someone describes what they want to buy, in their own words, in the channel they already use.
Ask only for missing detail
The agent asks the questions the policy actually needs answered, such as owner, term, and whether personal data is involved.
Check what already exists
It searches the contract store for an existing agreement or a preferred supplier covering the same thing, and links what it finds.
Apply the spend threshold
The relevant threshold and approval route are quoted from the policy, with the document cited.
Assemble the complete request
A request record is created with the answers, the policy applied, and any existing agreement attached.
The named approver decides
The request is routed to the approver the policy names. The agent does not approve and cannot commit spend.
Exactly what this agent can see, touch and change
The same five controls sit behind every ollo agent. These are this one's settings — visible before you build it, not buried in an admin screen afterwards.
Context
What reaches the modelProcurement teams fielding buying requests from across the business, especially where requesters do not know the thresholds and duplicate agreements go unnoticed.
Escalation
When it asks a personThe approver named in the policy decides before any spend is committed
Applications & Rights
Which tools it uses, and what it may do in each
NotionRead only
ConfluenceRead only
SharePointRead only
SlackReadWrites newCreates new records or documents. Never edits, moves or deletes anything that was already there.
JiraWrites newCreates new records or documents. Never edits, moves or deletes anything that was already there.Verification
How you know it’s rightEvery claim links to the document it came from. A statement the agent cannot cite does not make it into the output — which is what makes the result reviewable in minutes rather than re-read end to end.
Who it’s for
Procurement teams fielding buying requests from across the business, especially where requesters do not know the thresholds and duplicate agreements go unnoticed.
What you’ll need
- A published policy with thresholds
- A connected contract store
- A request queue to write to
- Named approvers per threshold
What you get
- A complete request record
- The policy and threshold applied
- Links to existing agreements found
What it doesn’t do
It gathers, checks and routes. It does not approve spend, negotiate with a supplier, raise a purchase order, or take a view on whether the organisation should buy the thing at all.
We build the first one with you
Not a template you configure alone. We sit with your team, build it on real data, and hand over the controls.
Scope
One session with the people who actually do the work. We agree what the agent reads, what it may write, and who approves.
Co-build
Built on your own data, not a sandbox. You watch it being made, so you know why it behaves the way it does.
Handover
You own the controls. Change the context, tighten the rights, move the approval gate — without coming back to us.
Parts of the work currently spread across the categories below. It does not replace any of those products outright.
Frequently asked
Can it approve small purchases automatically?
No. Even below a threshold, a named person approves. What changes is that the request arrives complete, with the policy and any existing agreement already attached, so the approval takes a moment rather than a fortnight.
How does it find a duplicate agreement?
It searches your contract store for the supplier, the category and the service described. It shows what it found and lets the approver decide whether it covers the request, because two similar agreements are not always interchangeable.
What if the requester will not answer the questions?
The request stays incomplete and is not routed. The agent shows the requester exactly which answers are missing and why the policy asks for them, rather than passing a half-formed request to an approver.
Does the same pattern work for legal review requests?
Yes, where you have a written route and named owners. Intake, policy check and routing behave the same way, and the co-build sets which questions each route asks.