Should digital passenger experience report to IT?
Digital passenger services need reliable IT delivery. The Authority function accountable for the passenger journey should set their day-to-day priorities.
People search for
In this article
In operating-model discussions with Authorities, this question often arises when a passenger app has been delivered successfully as a technical project but is difficult to change. The platform is stable, the security review is complete and the contract has reached its first milestone. Yet a disrupted journey can expose an unclear message, send a fare query to the wrong channel, or leave a journey-planning change out of step with the service on the ground.
IT has not failed in these circumstances. It has usually done what it was asked to do: procure and operate a secure, reliable system within budget. The gap is in ownership of passenger-facing decisions. This article does not address the branding, UX design and customer-experience aspects of a digital channel.
Put the owner close to service decisions
Passengers do not distinguish between an Authority's app, website, contact centre, station information and an Operator's on-the-day response. They need to know whether the bus is coming, whether their ticket is valid and what to do when the journey changes. One person or function needs the authority to set priorities across those channels, decide which problems to fix and hold the relevant Operator or Supplier to account for the result.
That owner will often sit in customer or service planning, or in a comparable function, depending on the Authority's scale and structure. The remit matters more than the departmental label. The role needs links to network planning, communications, contracts, customer insight and IT, as well as corporate affairs for branding, marketing and design.
IT should remain a central partner. It will normally own the technical architecture, cyber security, identity and access controls, integration standards and Supplier assurance. Moving a passenger app out of an IT reporting line must not bypass those controls. The passenger-service owner should decide the problem to solve and the evidence required before accepting a release. IT should apply proportionate controls and recognise that procurement of systems and Managed Services cannot use a one-size-fits-all approach.
What the reporting line changes
The difference appears in routine work. When a diversion is introduced, the Authority needs to establish that the feed reaches the app, the revised information is understandable, it appears before passengers leave home, the contact-centre script matches it, and the party responsible for correcting errors in the evenings and at weekends is clear.
Performance measures must cover more than availability, response time and defect resolution. A service owner can also examine how often passengers abandon a ticketing task, whether a particular disruption message generates avoidable contacts and whether a change creates an obstacle for people using assistive technology. Interpret these measures carefully. A fall in contacts may indicate a clearer service, or it may show that passengers gave up.
Digital evidence can remain within IT, provided access is agreed, data-quality responsibility is clear and people can relate it to service planning and contract performance. In several Authorities, people can see recurring passenger problems but cannot easily translate them into changes to the timetable, information process or Supplier obligation. That is the practical blockage, rather than a lack of data or dashboards.
Transport for London provides a large-scale illustration. Its executive team includes Alex Williams (at the time of writing) in a senior role covering customer and strategy, separate from the technical functions. TfL is not a template for every Authority. Its arrangement makes customer and strategic considerations visible at senior level. A smaller Authority can create similar clarity through one named lead, a modest team and a defined link to IT and Contract Management.
The operating model should fit the Authority's size and scale, with responsibilities clear across the organisation.
Start with work already under way
An Authority can improve the arrangement without creating a new department. Start by reviewing the next digital change: who approved the requirements, who will see the user evidence, who can require a Supplier to fix a problem after launch, and who owns the service after the project team disperses. Project documentation sometimes leaves these responsibilities implicit. They should be recorded in the service specification, acceptance criteria and operating arrangements.
A named owner also addresses a common handover problem. When a project closes, unresolved content, accessibility or data issues can drift between the IT team, communications team and Supplier. Keep an issue list that names the owner, due date and escalation route. It makes the reporting line operational.
Useful questions
Before changing the structure, test how the current service is governed:
- Who is accountable for the passenger outcome across the app, website, contact channels and physical service information?
- When a service change creates incorrect or confusing digital information, who can direct the relevant Operator or Supplier to correct it and check that it has been fixed?
- Do acceptance criteria include passenger tasks and service information, alongside security, availability and technical performance?
- Can the people responsible for planning and contracts see and use the passenger evidence held in digital systems?
- After a project closes, is there a named owner for releases, content, unresolved defects and the Supplier's ongoing obligations?
More on Organisational Design & Capability
