Ticketing and Transport Information Mobile App
High quality custom branded mobile apps for transport operators and local authorities.
- Travel information, for multiple transport modes, including bus and tram
- Secure mobile ticket purchase and delivery
- Ticket gifting to family and friends
- Secure digital tickets using QR codes
- Verification of child and student accounts
- Journey planning, travel departure and timetable information
- Live vehicle tracking
- Personalised travel disruption alerts
- Promotion of local attractions and events
- In app customer feedback
- Reduction in boarding times, especially at peak periods
- Increasing customer satisfaction levels through an easy to use interface
- Customers can plan journeys and purchase tickets at their convenience
- Fast track development and testing of marketing and pricing initiatives
- Increased efficiency with significantly lower total cost of transactions
- Quick and easy communication of travel disruptions
- Increased revenue through digital ticket sales
£21025 per instance
- Pricing document
- Skills Framework for the Information Age rate card
- Service definition document
- Terms and conditions
Passenger Technology Group Ltd
|Software add-on or extension||Yes, but can also be used as a standalone service|
|What software services is the service an extension to||Passenger Digital Services Platform|
|Cloud deployment model||Private cloud|
|Service constraints||Not applicable|
|Email or online ticketing support||Email or online ticketing|
|Support response times||Our standard contractual response time for support requests, during standard office hours, is 4 hours. However, we aim to provide an initial response to support requests within 1 hour during standard office hours.|
|User can manage status and priority of support tickets||No|
|Phone support availability||9 to 5 (UK time), Monday to Friday|
|Web chat support||No|
|Onsite support||Yes, at extra cost|
Our standard support package provides Help Desk cover from 9am - midnight, 7 days a week.
Our Help Desk Manager reports weekly analysis to the business management team, including support requests received and response times to ensure optimum performance by our Help Desk agents.
Our first line support agents have varying levels of technical expertise and are backed by a team of second line support agents.
|Support available to third parties||No|
Onboarding and offboarding
We have a defined 'onboarding' process that we follow with all users to capture all the information we need to deliver the service. This includes:
1) Key staff roles and contact details to identify responsibilities for sign off and training needs for users.
2) Collation of material to enable design and artwork to be completed.
3) Review of relevant company policies and procedures so relevant links can be provided.
4) Agreement on copy to make sure we have the right information to promote the service.
5) Assessment of the datasets and feeds we will need to set up the service.
6) Review of GDPR requirements for the service
7) Provision of relevant contact information to be provided as part of the service. For example, email addresses for, in app, user feedback to be sent to.
|End-of-contract data extraction||
Typically when a contract is terminated, the service will no longer be accessible to users. Exports of sales and revenue data will be provided. However, if required, at the end of the contract data may be held within the system and made accessible for 3 calendar months following the termination date of the contract.
The iOS and Google Play Store accounts are set up using the customers contact details as the main user and owner of the account. Therefore the ownership of these accounts and the associated analytics will remain accessible to the customer even though the app will have been removed.
The contract price includes:
1) Exporting historic sales and revenue data.
2) The termination of relevant services. For example, SIRI-SM and SIRI-VM services.
3) The removal of the iOS and Android apps from the Apple and Google Play stores.
4) Deletion of customer data from our supporting cloud based hosting infrastructure.
Sales data needs to be retained, following contract termination, for accounting purposes. The length of time sales data will be retained for will be agreed as part of the end of contract process.
Using the service
|Web browser interface||No|
|Application to install||Yes|
|Compatible operating systems||
|Designed for use on mobile devices||Yes|
|Differences between the mobile and desktop service||Not Applicable.|
|What users can and can't do using the API||Sales reporting to 3rd party systems.|
|API documentation formats||Other|
|API sandbox or test environment||Yes|
|Description of customisation||
The following items can be customised:
1) Mobile app branding can be customised to provide a bespoke look and feel. This customisation can only be completed by Passenger.
2) The following additional features can be provided on request: smart card portal, contactless payment portal, QR code support, live buses support to provide vehicle tracking, real time bus stop departure information and service updates that provide bus users with updates on disruptions to the transport network.
3) Bus users can tag their favourite bus stops, journey plans and timetables to get quick and easy access to the information they care about the most.
|Independence of resources||
We use a range of industry leading suppliers that provide reliable and scalable cloud computing services. We have designed and scaled our infrastructure to deal with current and forecasted demand based on historic data.
We have automated monitoring of our infrastructure that enables us to forecast future demand and scale our infrastructure, if required within minutes, to manage peaks in demand. This is reflected in the availability metric of our Digital Service Platform which is 99.9%. In addition, our iPhone and Android apps typically deliver a 99.5% crash free user experience.
|Service usage metrics||Yes|
There are numerous metrics provided by industry recognised services. The metrics include but are not limited to:
1) Number of active users per day.
2) Number of new users each day.
3) Crash free usage (%).
4) Adoption rates for new builds (%).
5) Median total time spent in the app per user.
6) Daily revenue.
|Reporting types||Real-time dashboards|
|Supplier type||Not a reseller|
|Staff security clearance||Staff screening not performed|
|Government security clearance||None|
|Knowledge of data storage and processing locations||Yes|
|Data storage and processing locations||United Kingdom|
|User control over data storage and processing locations||Yes|
|Datacentre security standards||Managed by a third party|
|Penetration testing frequency||Less than once a year|
|Penetration testing approach||In-house|
|Protecting data at rest||Scale, obfuscating techniques, or data storage sharding|
|Data sanitisation process||Yes|
|Data sanitisation type||
|Equipment disposal approach||In-house destruction process|
Data importing and exporting
|Data export formats||
|Other data export formats||
|Data import formats||Other|
|Other data import formats||TransXChange|
|Data protection between buyer and supplier networks||
|Data protection within supplier network||TLS (version 1.2 or above)|
Availability and resilience
The website and Passenger Digital Service Platform that provides underlying data to the website(s) has a service level agreement of 99% and a service level objective of 99.99%.
The Passenger iPhone and Android mobile apps typically deliver a 99.5% crash free user experience.
There is no refund mechanism for guaranteed levels of availability.
|Approach to resilience||
We use a range of industry leading suppliers that provide reliable and scalable cloud computing services. With guaranteed levels of service and support.
We have designed and scaled our infrastructure to deal with current and forecasted demand based on historic data. We have automated monitoring of our infrastructure that enables us to forecast future demand and scale our infrastructure, if required within minutes, to manage peaks in demand.
There are a number of ways that outages could be reported. For example:
1) Automated outage reporting - We monitor our key infrastructure and automatic error reports are provided. For example, if the demand on our infrastructure that is used to process mobile ticket purchases exceeds a fixed threshold an alert is generated and provided on to the relevant member(s) of our team.
2) User outage reporting - The mobile apps include a feedback form for users. Typically users will provide feedback when an outage occurs. All feedback is automatically reported to our internal systems which are pro-actively monitored by staff during normal working hours.
3) Customer outage reporting - Customer(s) may report an outage, in which case, this will be dealt with by our Help Desk Team.
Identity and authentication
|User authentication needed||No|
|Access restrictions in management interfaces and support channels||Access is granted via web portal and email. Web portal access is restricted to authorised users (user name and password). Strong passwords are enforced. Email requests are authorised by receiving an email at a pre-agreed domain or via a pre-agreed out-of-band mechanism such as SMS or phone.|
|Access restriction testing frequency||At least once a year|
|Management access authentication||
Audit information for users
|Access to user activity audit information||Users have access to real-time audit information|
|How long user audit data is stored for||At least 12 months|
|Access to supplier activity audit information||Users have access to real-time audit information|
|How long supplier audit data is stored for||At least 12 months|
|How long system logs are stored for||At least 12 months|
Standards and certifications
|ISO/IEC 27001 certification||No|
|ISO 28000:2007 certification||No|
|CSA STAR certification||No|
|Other security certifications||No|
|Named board-level person responsible for service security||Yes|
|Security governance certified||No|
|Security governance approach||
1) Communication Security - Valid TLS connections are used for communication and are tested against SSL Labs SSL Server Test. Communication with external systems is via TLS wherever possible.
2) System Configuration - Server software is kept up to date at least quarterly, with security patches typically being applied within 48 hours. All server software is configured and provisioned automatically with asset management tools. Test and development systems and applications are kept separate from production. Test systems are restricted to authorised users.
3) Database security - Parameterised queries are always used. Applications access databases with the lowest required credentials.
|Information security policies and processes||Ultimate responsibility for information security rests with the Chief Executive Officer of PTG, but on a day-to-day basis the Operations Director shall be responsible for managing and implementing the policy and related procedures. Line Managers are responsible for ensuring that their permanent and temporary staff and contractors are aware of: information security policies applicable in their work areas, personal responsibilities for information security and how to access advice on information security matters.|
|Configuration and change management standard||Supplier-defined controls|
|Configuration and change management approach||All infrastructure is managed as code in git source control management. Changes require peer review from a senior developer and output from runs are added to an append-only log.|
|Vulnerability management type||Supplier-defined controls|
|Vulnerability management approach||Software components in configuration management are automatically tested against security lists at frequent intervals. Threat information comes from Canonical's Ubuntu Security Notices, AWS security bulletins and Symfony Security Monitoring. Patches are deployed within 48 hours, with a target of 24 hours for any CVE with a base score over 5. Service provider security responsiveness is reviewed annually.|
|Protective monitoring type||Supplier-defined controls|
|Protective monitoring approach||Compromises are identified from network ingress/egress alerts and extensive application event monitoring alerts. Response process includes review from a senior developer with a target response time of 1 hour.|
|Incident management type||Supplier-defined controls|
|Incident management approach||Users report incidents email (optionally with PGP), documented via the well-known security.txt standard. Reports are provided to impacted users via email within 1 week of incident. Processes are in place for incidents such as DDoS, personal or confidential data exposure.|
|Approach to secure software development best practice||Conforms to a recognised standard, but self-assessed|
Public sector networks
|Connection to public sector networks||No|
|Price||£21025 per instance|
|Discount for educational organisations||No|
|Free trial available||No|