Solving the business issues with deep aggregation

[Erdem Ovacik]

Hi all, as Donkey Republic we are keen to be a part of the aggregators; already working with a number of them across Europe. 

As we see it, there's three levels of aggregation; 

1) aggregator conveys availability and pricing, rest of service via service App

2) aggregator charges customers, after payment the service App is use to complete the service. 

3) all service works on the aggregator; including charging, and getting access to the assets. 

Currently, the aggregations we work with are on the first level. 

For the 2nd and 3rd levels, I'd like to hear thoughts on how to overcome the below challenges: 

a) the service app conveys a lot of communication towards the customer to educate them on using the service correctly. For example, in some cities, we would like to show the user how to leash the bike correctly. How does the aggregator assume responsibility in educating / instructing the customer to use the service in the correct way? 

b) what happens when a customer doesn't return the asset? Our current practices require us to charge a penalty; do the aggregator commit in paying us this penalty? 

c) there are various data points we use to improve our service. for example, we would like to know how far the customer is when they look for one of our bikes, from the nearest bike. Can we establish various data points that we expect to collect from the aggregators? 

d) could the aggregator support marketing? One route is referrals, ie that a user gets the benefit of recommending our system to friends, who get a discount. Another one with notifications when we do campaigns towards the riders? 

Thanks a lot!

[Sven Boor]

Dear Erdem,

Thanks for reaching out!

We have defined 3 stages (unfortunately the minutes of the meetings are not made available here yet), the end goal is to reach stage 3:

1. Making the positions of all bikes available (so that they can shown on a map or included in a travel advice).

2. Unlocking/reserving via a deep link to the app of the bike operator.

3. Making in-app (that means at the aggregator side) unlocking and reservation of bikes possible. 

What you describe as level 1 is the goal of the stage 1 and 2 we defined. That's relatively easy to do and already great for providing better travel advices to travellers (great marketing tool in my opinion). We would like to standardise this by using GBFS with some extensions (GBFS+ see here https://docs.google.com/document/d/13rzPYHhkPT_DQ9pkS1Os78JhEuwNIch9KynjkurXrPc/edit and here https://groups.google.com/forum/#!topic/openbikeshare/osJpDw_yTLk).

For phase 3 (that's your level 3) there are still a lot of challenges it would be really cool if we achieve that in the end, I do like to give my personal views to start a discussion. 

a) the service app conveys a lot of communication towards the customer to educate them on using the service correctly. For example, in some cities, we would like to show the user how to leash the bike correctly. How does the aggregator assume responsibility in educating / instructing the customer to use the service in the correct way? 

The aggregator will be responsible, it would be a good idea to standardise the communication so that the aggregator don't have to write new instructions for every bike party they integrate.  

 

b) what happens when a customer doesn't return the asset? Our current practices require us to charge a penalty; do the aggregator commit in paying us this penalty? 

Yes, the aggregator is responsible, instead of renting out the asset to a user you are renting it out to the aggregator (also good from a privacy perspective). The aggregator can of course make the customer responsible for the penalty.  

 

c) there are various data points we use to improve our service. for example, we would like to know how far the customer is when they look for one of our bikes, from the nearest bike. Can we establish various data points that we expect to collect from the aggregators? 

That would be a good idea, currently there is a similar discussion going on about such data for public transport as well https://ovmagazine.nl/2018/08/een-onmogelijk-reisadvies-1430/ (Unfortunately dutch). By knowing where (potential) customers originate from and where they want to go the supply of bicycles (and other modes of transport) can be better fitted to the demand. 

d) could the aggregator support marketing? One route is referrals, ie that a user gets the benefit of recommending our system to friends, who get a discount. Another one with notifications when we do campaigns towards the riders? 

I don't think this is something you should ask to an aggregator (for me an aggregator is a party like https://tranzer.com/). An aggregator should have his own marketing (but they can do some specific marketing actions for bike share of course). Bike operators are completely free to have their own applications as well where they can do referals and campaigns 

Just some thoughts, would like to hear your view (and from others) as well.

Best regards,

Sven Boor