OneFleet

Enterprise fleet management is not a single workflow — it is the continuous coordination of fuel spend, card controls, driver compliance, and financial reconciliation across organisations that may operate hundreds of vehicles, dozens of cost centres, and multiple delegated account hierarchies simultaneously. A fleet administrator at a logistics company is not managing one account. They are managing a live operational system: enforcing spend limits in near-real-time, resolving card disputes before drivers are stranded mid-route, and maintaining account structures that reflect a workforce that changes weekly. The consequence of a delayed or failed transaction is not inconvenience — it is operational disruption at scale.

At the volume OneFleet operates — approximately 12 million transactions per month across 500,000+ customers — small interface failures compound into significant operational overhead. A workflow that requires three screens to resolve a card dispute adds support burden across thousands of accounts. An invoicing module that cannot surface cost allocation by driver group forces manual export and reconciliation. The platform does not just support operations; it is a direct input to how fleet operators make decisions, control costs, and report to their finance teams.

Cross-border fleet operations in the EU carry a layer of regulatory complexity that most enterprise software does not have to accommodate. VAT reclaim rules differ by market — the mechanisms for fuel tax recovery vary between the UK, Germany, France, and the Netherlands. Card acceptance networks vary by country. Compliance reporting obligations are market-specific. A platform serving customers across six EU markets must present a coherent operational interface while silently carrying the weight of market-level regulatory variance underneath it. Exposing that complexity to the fleet administrator would make the product unusable. Hiding it incorrectly creates compliance risk.

The UX challenge is not simply to make individual screens easier to use. It is to design an interaction model that remains legible under operational pressure — for a fleet administrator managing 300 vehicles, a finance controller reconciling cross-market invoices, and a driver expecting a card to work at a fuel station 400 kilometres from their base. Each of these users operates on a different timescale and with a different tolerance for failure.

Research began with contextual inquiry sessions with fleet administrators and finance controllers across six European markets — observing operators in their actual working environments, not reconstructed lab scenarios. The goal was to map task flows as they were actually executed, including the workarounds operators had developed to compensate for platform gaps that no support ticket had formally captured.

The most significant findings did not come from interview questions. They came from observation: operators using browser history as a navigation tool between modules, maintaining private spreadsheets to track account structure changes the platform could not represent, and escalating card disputes to support not because they lacked authorisation but because the self-service path was not trusted to work.

Stakeholder interviews with IT administrators, account managers, and bp commercial team members surfaced a second layer of complexity: the operational cost of supporting clients through tasks the platform made unnecessarily difficult, and the downstream effect on renewal conversations when fleet administrators reported low confidence in the tool.

A critical finding from cross-market sessions: task flows were not uniform across markets. The same workflow — invoice reconciliation, for instance — required meaningfully different steps and data access patterns in Germany versus France versus the UK, driven by local VAT and reporting structures. The interaction model had to accommodate this variance without producing market-specific product forks.

The first three months produced no visible product screens. They produced bpCore — the design system that made the rest of the work viable. Building the shared token architecture and component library before any squad touched their product surfaces was a contested decision under delivery pressure. It was the right one: without a common foundation, every screen-level improvement would have compounded the inconsistency we were trying to resolve.

Navigation was restructured around the account hierarchy rather than the feature taxonomy. Any primary workflow reachable within three interactions from a given account context. The account record became the persistent anchor — card management, transaction history, invoices, and driver groups all accessible from within the account view rather than requiring module navigation.

Form architecture across all verticals was restructured to follow task sequence rather than data model. Fields grouped by what an operator needs to know at each decision point, not by how the underlying data is stored. Progressive disclosure applied to reduce cognitive load on complex multi-step workflows — compliance fields surfaced at the step where they became decision-relevant.

Cross-squad governance was established alongside the design system. A pattern review process required any new interaction pattern proposed by a squad to be validated against the shared grammar before implementation. This was not a bureaucratic gate — it was the mechanism by which consistency remained a live property of the platform rather than something that decayed between release cycles.

Design was moved upstream into the planning process. That meant arriving at roadmap sessions with a defined problem framing and measurable success criteria — not a solution. Scope decisions were shaped at the point where they were cheapest to make, not after engineering estimates had already been committed. This changed the nature of design’s relationship to the product organisation from delivery executor to planning co-author.

Usability testing ran throughout — not as a sign-off gate but as a continuous input. Every significant interaction change was validated with fleet operators before shipping. The test population included experienced administrators and new operators, because the metric we were optimising for was time-to-proficiency on complex tasks, not just completion rate at steady state.