Do You Really Need an App? Ask Yourself Why First
Apps are #1 on the digital transformation wishlist, but unless you know why you’re doing it, you may end up wasting your money. But the good news is that if the app addresses a real customer pain point, the benefits will keep coming.
Here’s what we learned at Naked Bus.
Once Upon a Time, There were no Apps
We’ve all seen the bus driver with a clipboard, ticking off names as passengers get on the bus. It works fine when everyone is being picked up at the same place.
At Naked Bus we used to do the same thing.
Naked Bus was a low cost, long distance bus service operating across New Zealand. Think of it as Ryanair, SouthWest or JetStar (but a bit nicer), on the ground.
What started as a tool to increase revenue, became a key component of improving customer experience.
The Waybill (or manifest) would be emailed automatically to a location where the driver could print it out, an hour before departure, and no bookings were taken after that time. It was very low cost because the system automated the delivery of the waybill, automatically cutting off future bookings. We could run hundreds of journeys a day without requiring any staff to administer the process.
But, by cutting off bookings before the bus left the depot, we were losing potential revenue. It’s not as simple as losing that hour before departure. Take a bus travelling from Auckland to Wellington. It might have 20 pickups en route. Hamilton pickups would be cut off 3 hours before departure, and Palmerston North pickups would be cut off a whopping 10 hours before departure.
Our customers did not care about the technical or logistical constraints. They just wanted to book a bus ticket, and often they couldn’t for a whole day ahead.
The problem is that it is hard to communicate new bookings to drivers while they are driving.
There were two obvious alternatives:
- phone the driver with each new booking. This is what our competitors did. However it is labour-intensive and error-prone (the driver has to manually amend the waybill each time, and any manual information hand-off increases error rates, as well as being potentially dangerous (drivers tempted to answer the phone while driving)
email the driver with each new booking. We could have automated this quite simply. But again it was error-prone as now the driver needed to look in two places for bookings.
A Zero Defects Approach is Key to Great CX
- Our business depended on reducing errors (errors are costly – each error that leads to a passenger not being picked up costs the business an average of four hours in admin time, plus the reputational damage) and reducing administration cost (manually transmitting bookings to drivers) so we could offer the lowest price tickets to our customers.
So, we decided on Plan C.
But there wasn’t a Plan C, because no bus company in the world was doing it in a different way.
Getting to Plan C
At Naked Bus, we always started with the Vision: To be the best low cost travel solution.
So any solution needed to:
- be low administration cost
- generate more revenue (i.e. more people can make bookings because bookings are not closed off one hour before departure)
- have a very low error rate
- be fast and easy to use for drivers.
It was clear that displaying bookings on a mobile device in a “live” view would be low cost and enable us to take bookings closer to departure.
Our first thought was to display bookings in a mobile browser page. But there were two major problems:
Naked Buses were travelling the length and breadth of the country and there were sizeable areas with no mobile coverage. It was imperative that the data was available at all times and HTML5 (to store the information) wasn’t a thing yet.
Many of our drivers were not technically skilled. This was late 2006, and the iPhone had not been invented. Phones were hard to use.
So we decided to create a phone app, using Java, that would store all the bookings for that trip. Using an App allowed us to store the data on the phone for when it was out of coverage.
The app … increased revenue 10% overnight
Using an App also meant we could control the user (driver) experience, making it easy and intuitive to use.
We built the original app in Java on a Nokia 6234 in February 2007 (the Apple Appstore didn’t open until July 2008). The App was rebuilt for Android in 2011.
The idea was that the App would sync with the database continuously, and become the single source of truth for bookings for the drivers. We could deselect real time bookings for locations (generally low volume) where there was no coverage.
And that’s pretty much all the App did to start with (We used an MVP-type approach long before we had heard of the term).
And it worked – increasing revenue around 10% overnight.
Leverage the Technology to Address Customer Pain Points
But serendipitously we found that the App gave us other customer benefits.
As well as giving the driver a list of bookings, sorted by location for that journey, we allowed the driver to “tick” passengers off when they boarded. This tick was time-stamped and stored in the database in real time. Suddenly we knew, without GPS, when the bus was at a bus stop. This pretty much put an end to disputes about buses not turning up or being late or early without the driver having to do anything else.
We took that one stage further, and created a script that identified all buses that had not reached a bus stop within x minutes of schedule. Now we had a dashboard of late running buses, and we could proactively inform waiting passengers when a bus was late, again without the driver having to do anything, and again without relying on GPS. We found that customers did not mind waiting so much if they knew how long the delay would be. They could now go and get a cup of coffee. The key was that we had all but eliminated what we called “bus stop anxiety” – not knowing when the bus was coming, or, if, in fact they had missed the bus.
And, as we looked at the data, and the technology, we came up with other benefits
- We could communicate with driver through push messaging.
- The App could alert bus drivers when connecting buses were late so they would know to wait. In the case of delays, drivers could communicate with each other through the App (often these drivers were employed by different companies, so keeping a manual phone list up to date was hard).
- We developed the ability for the driver to sell tickets through the App including for tickets on connecting journeys, with the App interrogating available capacity across the network in real time.
- We modified the screens so bus drivers were presented with the right info for the passenger at the time of boarding – e.g. if they are changing bus, when, where, how long the wait is.
So what started as a tool to increase revenue, and keep costs low, became a key component of improving customer experience.
There were many takeouts from this journey:
- Start from the vision; know where you are going, but start small (MVP).
- As you automate, you will generate a lot – a huge amount – of data. Keep it and figure out how to use it to improve the customer experience.
- APIs are your friend. We could develop asynchronously for the main booking system and the App, because they communicated through a stable API.
- Pick the right technology, but don’t get hung up on it. A Java App on a Nokia phone was the right thing in 2007. In 2011, an Android App was a far better bet – meaning that we had more flexibility in devices, and we could integrate with much of the technology on the phone
- After the vision is clear, engage a cross-functional team early on. At different times, IT, Operations, CX / Customer service, Marketing and Finance were all involved. Without them we would not have leveraged the data as we did.
A Digital Transformation Checklist
- Clarify the Vision
- What is the pain-point you are trying to solve
- What is the solution, or solutions, that will take you closer to the vision?
- What is the minimum viable product you can build to test whether the solution works
- What is the roadmap to capturing other benefits? (Involve other teams)
- Has the wishlist been prioritised?
- Measure, rinse and repeat.
I hope that was a useful case study of digital transformation in action. Feel free to let me know in comments what your own experience has been.
Hamish Nuttall launched nakedbus.com, a low cost, internet-based long distance bus company in New Zealand in 2006. Hamish integrated marketing, IT, operations and CX, harnessing Agile, Theory of Constraints, and Lean Startup methodologies to deliver rapid growth.
Naked Bus achieved 40% market share, carrying 700,000 passengers per year, 25-40% year on year growth and a Net Promoter Score of +65.
Following its sale in early 2015, he now works with organisations to help them in their digital transformation.
Contact Hamish at firstname.lastname@example.org.