How many have you heard that you need APIs for digital transformation? How about that this also requires cultural transformation? Let me guess: too many! Businesses are struggling when it comes to knowing what to look for, what actions to take, and how to make digital transformation work.
Digital transformation is more than just technology. Digital transformation prepares organizations to leverage the benefits of new technology to create business value. It applies to APIs, as well as any other technologies.
From this article series, you’ll learn the common road blockers and catalysts that make or break an organization’s digital transformation journey. It helped me to assess an organization’s situation and conclude what actions to take.
In part one, I’ll discuss how we digitalized the traditional assisted transport service of an NGO, as well as the reasons why we did it. It demonstrates the transitional change from digitization to digitalization.
Figure 1: The Pyramid of Digital Transformation shows the three levels: digitization, digitalization, and digital transformation. The change from digitization to digitalization is transitional. The change from digitalization to digital transformation is transform.
Then, I’ll show how we evolved it into an API product that enables new digital business. It demonstrates the transformative change from digitalization to digital transformation. This transformational change is the most challenging as it requires businesses to evolve.
In part two, I’ll present the blockers and catalysts that make or break digital transformation. It’s based on our first-hand experience at the NGO and at many other organizations across industries (e.g. telecommunications, financial services, manufacturing, and healthcare).
What’s at stake
Our NGO is a non-profit organization. Its purpose is to protect the lives, health, and dignity of people in need. It’s organized as one agency and multiple regional associations. Associations provide services in one region while the agency provides them with infrastructure and common services (e.g., assisted transport application and fundraising service).
But why are they trying to become digital? I’ll present the two primary reasons why this NGO started their digital transformation journey.
Customer base is not sustainable
Our NGO has three main customer segments who donate or provide volunteering: seniors, young people, and adults.
Many seniors pass on their fortune to this NGO. They grew up in the post-war period and saw firsthand the significant impact it had on their community. As a result, they have a high emotional bond with this NGO and want to support it with their last will.
Young people have different priorities. According to a survey conducted by the World Economic Forum (WEF), young people’s priority is climate change. Unlike seniors, adults don’t have the same emotional bond with this NGO. Parents care about the future of their kids and therefore care about other causes (e.g., climate change and the future of humanity).
In summary, our NGO is facing a shrinking, unsustainable customer base. Furthermore, volunteers want to make an impact on people’s lives. However, volunteering often involves cumbersome paperwork, especially reporting. Digitalization shows great promise for increasing volunteering experience.
NGOs never get disrupted!?
Well, welcome to reality! Every industry gets disrupted, NGOs are no exception. For instance, Uber started offering two products that compete with the assisted transport service: Uber WAV and Uber Health.
With Uber WAV, people tied to wheelchairs can order a ride in a wheelchair-accessible vehicle (WAV) with all the comfort of the Uber experience. The drivers are certified to assist people with disabilities.
With Uber Health, Uber helps healthcare organizations getting fewer no-shows and more on-time appointments, which reduces idle times for specialists. With this goal, they provide a specialized product to order and manage rides for clients.
In summary, the NGO is facing new competitors disrupting the market. Also, new NGOs compete for donations. Our NGO needed to rethink how it generates funds to help people, what problems to solve, and how.
Traditional assisted transport service
Regional associations provide assisted transport services to people with disabilities or unable to use public transportation. The agency provides associations an assisted transport application. With this application, associations manage transports, coordinate volunteers, and charge customers.
Revenue model of traditional assisted transport service
The revenue model consists of four main parties: end-customer, volunteer, association, and agency. The following image illustrates the revenue model:
Figure 2: The revenue model of today’s assisted transport service: The customer gets a ride to his medical appointment and pays for it.
In the following, I’ll explain the value and revenue stream for each party.
- End-customer: The customer orders a ride to his medical appointment from the association. The customer gets a ride. In return, he pays a fee to the association.
- Association: The association coordinates volunteers and assigns volunteers to driving jobs. It charges the customer a fee for the ride. From this fee, it reimburses the volunteer’s expenses and pays the agency for using the assisted transport application.
- Volunteer: The volunteer drives the customer to the destination and back again. He fills the report form, sends it to the association, and waits for the reimbursement of his expenses (e.g. gas and parking tickets).
- Agency: The agency provides the assisted transport application to the association. In return, it receives a usage fee from the association.
Assisted transport service as API solution
We run a design sprint. The design sprint is a human-centric approach to identifying problems and validate feasible solutions in just one week. We invited people from associations and experienced volunteers.
As a result, we identified one big pain point: reporting. After every ride, volunteers file a report form to provide the driving distance and the duration. They have to fill the yellow report form when the end-customer pays cash or a green one when the end-customer pays on the account. At the end of the month, they have to send report piles to the association to get compensated for expenses.
The association collects all report forms and enters its details into the assisted transport application to start the charging process.
API solution: reporting
We created a reporting mobile app that provides volunteers their driving assignments and automatizes reporting of driving distance and duration. To this goal, we designed the Reporting API that feeds the reporting mobile app with driving assignments and receives report information. The reporting mobile app replaces report forms (digitization) and automates the reporting process (digitalization).
Here’s a simplified specification of the Reporting API:
# REPORTING API
## Gets all transports.
GET /transports
[ ... ]
## Reports details for a specific transport.
POST /reports
{
'transportId': '123',
'distance': '4.5km',
'duration': '2.2h'
}
Business value of an API solution
Besides digitizing the reports, this solution digitalizes and automates the reporting process to save costs and increase timely charging. The reporting process remains more efficient, faster, real-time, and automated. No structural change, no organizational change required.
Revenue model of reporting mobile app-based on API solution
The revenue model consists of four main parties: end-customer, volunteer, association, and agency. The most significant change is that the agency provides value to the volunteer and the association through the reporting mobile app and digitalized reporting process.
Figure 3: The revenue model of assisted transport with the reporting mobile app: The revenue streams remain the same as in the traditional revenue streams. However, the assisted transport application and reporting mobile app provide more value to the association.
- End-Customer: The customer orders a ride to his medical appointment from the association. The customer gets a ride. In return, he pays a fee to the association.
- Association: The association coordinates volunteers and assigns volunteers to driving jobs. It charges the customer a fee for the ride. From this fee, it reimburses the volunteer’s expenses and pays the agency for using the assisted transport application.
- Volunteer: The volunteer drives the customer to the destination and back again. He uses the reporting mobile app, which automatically sends reports to the assisted transport application. Afterward, he receives reimbursement for his expenses.
- Agency: The agency provides the assisted transport application and digitalized reporting process. Further, it gives volunteers the reporting mobile app, which automatizes the reporting process. In return, it receives a usage fee from the association.
Currently, twelve associations are using the agency’s assisted transport application. The pricing of the Reporting app is $600 per month and $6 per active driver and month. Let’s assume they all have 1,600 active drivers in total. Based on the current pricing model, it creates approximately a revenue of $200k per year for the agency to operate and extend it with more features.
Assisted transport service as API product
According to Uber, over 3.6 million Americans miss their medical appointments due to a lack of reliable transportation. If we scale it down to the population of Switzerland, that’s 85K people. A doctor in Zurich, Switzerland, charges $135 per 15min. Making the math, that’s $11.5M loss for healthcare organizations in Switzerland.
What if we can offer healthcare organizations reliable transportation for their clients. Healthcare organizations will have fewer no-shows and more on-time appointments to reduce idle time of specialists. What if we can provide an interface to this value proposition?
API product: Transport Care
We designed the API product Transport Care. It allows healthcare organizations to order and manage assisted transports for their clients. The Transports API is similar to the Reporting API. Further, the reporting mobile app uses the Transports API instead of the Reporting API with minor modifications. The API product, Transport Care, empowers health organizations to order rides for their clients to get fewer no-shows. That’s a digital business (digital transformation).
Here’s a simplified specification of the Transports API:
# TRANSPORTS API
## Gets all transports.
GET /transports
[ ... ]
## Creates a new driving assignment.
POST /transports
{ ... }
## Updates the driving assignment with info that are reporting relevant.
PUT /transports/123
{
'distance': '4.5km'
'duration': '2.2h'
}
Business value of API product
This API product enables a new digital business model. Healthcare organizations pay for the API product because they lose less money from no-shows. It may even generate enough revenue such that associations would get the assisted transport application and reporting mobile app for free. Plus, all the prior benefits of digitalization: automated, more efficient, and faster.
Revenue model of Transport Care
The revenue model consists of five parties: healthcare organization, end-customer, volunteer, association, and agency. The following image illustrates the revenue model. The most significant change is that the healthcare organization pays the NGO for the assisted transport service. That’s an entirely new revenue stream and complements the income from fundraising and donations.
Figure 4: The revenue model of API product Transport Care: Healthcare organizations become the new revenue source for the assisted transport service.
- Healthcare organization: The healthcare organization uses Transport Care APIs to order rides. Its motivation is to lower no-shows and increase on-time appointments. It pays the agency a fee for ordering rides via an API.
- End-customer: The customer gets a ride to his medical appointment.
- Association: The association coordinates volunteers and assigns volunteers to driving jobs. It receives compensation from the agency. From this compensation, it reimburses the volunteer’s expenses.
- Volunteer: The volunteer drives the customer to the destination and back again. He uses the reporting mobile app, which automatically sends reports to the assisted transport application. Afterward, he receives reimbursement for those expenses (e.g., gas and parking tickets).
- Agency: The agency provides the API to healthcare organizations. It provides the assisted transport application and digitalized reporting process to the association. It offers volunteers the reporting mobile, which automatizes the reporting process.
Healthcare organizations in Switzerland may save approx. $11.5M per year. If we charge friction of it, e.g. $1M per year, which is five times more than the income from the API solution with approx. $0.2M per year. That’s the significant difference between the two breeds of API: API products and API solutions. API solutions digitalize a business process while API products create digital business opportunities.
API product never made it
This API product remains on-hold even though it promises business value. The reasons for this were that it lacked IT governance, accountability, and a digital and entrepreneurial mindset to manage and grow into a digital product. Therefore, this an API that was just another project. These reasons represent some of the blockers and catalysts of digital transformation that I discuss in more detail in part two.
The good news: this API product demonstrated the value of what could be. That’s one of the reasons why today, the NGO is working on IT governance and evangelizing a digital mindset.
For more information on APIs as products, read other MuleSoft blogs.
