Another card request, another email chain
An office site you manage has chargers for staff and visitors. Staff charge at a reduced rate with an RFID card, visitors pay by app. Every week the facilities manager emails a list: three new starters who need cards, one who lost theirs, a contractor who needs access for a month, and someone who left in the spring and is apparently still charging at the staff rate.
Your support person adds and removes drivers in the back office by hand, posts cards, and replies to the facilities manager. When they are off, the list waits.
Access is managed by the wrong people
The site knows who should have access. You hold the platform where access is set. Neither side has a clean way to hand over the information, so it moves by email, loses detail, and leaves no record of who approved what. Leavers are the weakest link, because nobody tells you when someone leaves.
- Requests arrive as emails and spreadsheets in different formats.
- There is no record of who approved each driver.
- Card numbers are not linked to named drivers reliably.
- Temporary access has no end date, so it never ends.
- Staff and visitor tariffs are assigned by hand, sometimes wrongly.
The cost of loose access
Former staff charging at staff rates cost the site money, and the site will ask why. Lost cards stay active. Your support team spends hours on routine admin that earns nothing. And the site's finance team cannot reconcile staff charging to a list of eligible people, which becomes a problem when charging is treated as a benefit.
Visitor and fleet use complicates it further. Some sites give pool vehicles their own cards, some let visiting contractors charge free for a period, and some bill departments internally. Each of those is a tariff group someone set by hand, and each can drift out of date.
The access flow we build
- Each site gets a simple request page for its nominated approvers: add a driver, replace a card, set temporary access with an end date, remove a leaver.
- Drivers can request access themselves, and the request goes to the site approver first.
- Approved requests update your charge point management system through its API: driver added, card linked, tariff group assigned. Where there is no API, the change is queued for your team with every detail filled in.
- Cards are tracked by number from stock, to posted, to active, to cancelled.
- Temporary access ends automatically on its date, and the site gets a periodic list of active drivers to confirm.
- Every change is logged with who asked, who approved and when.
| Task | By email now | With the access flow |
|---|---|---|
| New driver | Email, typed into platform | Approved request updates platform |
| Lost card | Old card stays active | Cancelled when the new one issues |
| Contractor access | No end date | Ends automatically |
| Leavers | Rarely reported | Periodic confirmation by the site |
| Audit | Search the inbox | Log of every change |
Who is eligible and on what tariff is the site's decision. The flow records and applies it.
Access that stays accurate
Sites manage their own drivers without waiting on your inbox. Your support team handles exceptions, not routine additions. Leavers drop off. The site's finance team gets a list of eligible drivers and their charging, which they can reconcile. And when a site asks who approved a particular driver, you can show them.
Your support team also gets a clear answer when a driver rings to say their card does not work: whether the card is active, which tariff group it is in and who approved it, without an email to the site asking.
Do your workplace sites work like this?
- Card requests arrive by email every week.
- Former staff still have active cards.
- Temporary access never gets removed.
- Nobody can show who approved a given driver.
- Tariff groups are assigned by hand.