Six suppliers, eleven requests, one inbox
A new client has sites with several different suppliers. To prepare their tender, your analyst emails each supplier's broker team with the LOA attached, asking for consumption data and current contract terms. Two replies come back within days. One supplier wants the request through its portal instead. One replies asking for a different LOA format. Two do not reply at all.
Three weeks later, the account manager asks where the data is. The analyst scrolls through the shared inbox to work out who replied, who asked for something, and who has gone silent.
Why requests fall through the cracks
Supplier data requests are small individually, but a busy consultancy sends a lot of them, and each one has its own route and timetable.
- Different suppliers want requests by email, portal or a specific form.
- Replies arrive in the shared inbox, often without the reference you used.
- Some replies are partial, answering one meter but not another.
- Nobody owns the list of outstanding requests.
- Files received are saved wherever the person opening them chooses.
Slow data, slow renewals
Everything downstream depends on the data: comparing offers, checking current contracts and advising the client. When requests stall, tenders start late and time runs short near the end date.
Analysts spend hours searching inboxes and re-sending requests. Replies that are received but misfiled get requested again, which annoys suppliers' broker desks. And when a client asks for an update, nobody can give a straight answer.
The problem is worst when someone is off. Requests sent from one analyst's own mailbox, or tracked in their personal notes, simply stop moving during a holiday. The replies arrive, but nobody else knows they were expected or what they relate to.
A request tracker from ask to answer
We build a request tracker around the way suppliers actually respond.
- Each request is created against the client and the meters it covers, with the supplier, the data asked for and the LOA used.
- The tracker knows each supplier's preferred route and sends by email where that is accepted, or creates a task for a person to submit it through a portal.
- Replies arriving in the shared inbox are matched to open requests by supplier, meter numbers and account numbers, using a parser and a language model to read the reply. Uncertain matches go to a person.
- Attachments are filed against the client and meters automatically, and the request is marked complete or partly complete.
- Requests with no reply after a period you set are chased automatically, then escalated to a person.
- A board shows outstanding requests by client, supplier and age, so the team sees what is holding up each tender.
| Stage | Inbox and memory | Request tracker |
|---|---|---|
| Sending | Email from whoever is working on it | Logged with meters and LOA |
| Portal suppliers | Remembered, sometimes | Task created for a person |
| Reply received | Found by searching | Matched to the request |
| Files | Saved anywhere | Filed against client and meters |
| No reply | Noticed when someone asks | Chased on a schedule |
Suppliers' response times are outside anyone's control. The tracker makes sure nothing is waiting because it was forgotten on your side.
Tenders that start with the data in hand
When the analyst prepares a tender, the tracker shows what has arrived, what is partial and what is outstanding for each meter. Chasing has been happening in the background. The account manager can tell the client exactly what is still awaited, and from whom.
Supplier desks receive fewer duplicate requests, and your team stops searching the inbox for files that were already received.
Are your data requests disappearing?
- Supplier data requests are tracked in people's heads.
- You search the shared inbox to see who has replied.
- Requests have been sent twice because replies were misfiled.
- Tenders start late waiting for supplier data.
- Nobody can list outstanding requests for a client.