Six tabs open and a phone ringing
Your bookers start the day with several browser tabs open: the portals and vendor systems of each trust you supply, a shared inbox for trusts and care homes that email, and the phone for the rest. New shifts appear on the portals throughout the day, often released to several agencies at once. The first agency to put forward a suitable, compliant nurse usually gets it.
Every few minutes someone refreshes each tab. Shifts that come in while the booker is on the phone are seen late. At the end of the day, nobody can say exactly how many requests came in, from where, and how many were filled.
Why requests are so scattered
Each trust chooses its own way of releasing shifts to agencies. Some use a neutral vendor or vendor management system, some a staffing portal, some still email. Care homes and private hospitals phone. None of these talk to your booking system.
- Each portal has its own login, layout and notification method.
- Email requests come in free text, with grade and ward written differently each time.
- Portal notifications are often generic emails that still require a login to see the detail.
- Bookers have to retype each request into your own system to work on it.
- Filling the shift means updating the portal as well as your system, twice.
What the scatter costs
Speed is what wins shifts, and the scatter makes you slow. Shifts are lost to agencies that responded first. Bookers spend time refreshing and retyping instead of calling nurses. Double entry means mistakes: a nurse confirmed in your system but not on the portal, or the reverse. And without a record of all requests, you cannot see which trusts, wards or grades you are losing.
| Channel | Typical handling today | In a single shift inbox |
|---|---|---|
| Trust portal or vendor system | Refresh and retype | Read through an available integration or export, where permitted |
| Portal notification emails | Open, then log in | Parsed for the shift details and link |
| Emailed requests | Read and retype | Read by a parser, checked by a booker |
| Phone requests | Written on a pad | Logged on a quick entry form |
How we build the single shift inbox
- For each portal, we look at what the operator allows: an API, a data feed, email notifications or exports. We use only methods permitted by the portal's terms.
- Notification emails and emailed requests are read by a parser, which may use an AI model for free text, to extract client, ward, grade, specialty, date and times. A booker confirms anything uncertain.
- Phone requests are logged in a quick entry form so they join the same list.
- Every request appears in one inbox, standardised, with the time it arrived and the source.
- Each request is matched against nurses who are available, compliant for that client and have the right grade and specialty, ready for the booker to offer.
- When a nurse is confirmed, the booker is prompted to confirm on the portal, and where the portal allows it, the confirmation is sent automatically.
- Reports show requests, fills and losses by client, ward, grade and source.
Where a portal allows no automated access, we do not try to scrape it against its terms. We make the rest of the work faster and keep a clear prompt for the manual step.
A day with one list
Bookers work from one list, in order of arrival and urgency, with suitable nurses already suggested. Nothing is retyped. The portal update is prompted or done for them. And at the end of the week, you can see where your requests came from and where you are losing shifts, which is the start of a real conversation about recruitment and pricing.
Does this describe your booking desk?
- Bookers refresh several trust portals throughout the day.
- Shifts are lost because they were seen late.
- Requests are retyped from portals and emails into your system.
- Confirmations have been missed on a portal.
- You cannot say how many requests you received last month or where from.