There’s an Uber for doctors, cleaners, cookies. For booze, for flowers, and even movers. With almost any product or service available on demand, real-time communications is one of the most important features to set your “Uber for X” apart from the rest.
I recently spoke at this year’s API World, held in September and with 1000+ participants about the on-demand economy and how real-time communications is key for any successful business.
I want to talk about the on-demand economy, or the “Uber but for X” economy. Many of you are probably thinking about the next segment to disrupt the Uber way. Sinch provides app developers with ways of adding real-time communications, like voice, video and even verification, to their apps. In my spare time, one of the things I enjoy doing is watching my 11-year old son do magic tricks.
The fun thing with watching kids succeed in something, is the pure joy in their eyes when they do it. As a loving father, I want my son to be able to make a living out of something he loves, just like I have. I’d like to share an idea of mine: When you feel a bit down, when you forgot you wife’s birthday, or when your recent Uber for X startup went bust – what do you do? You get Magic on demand. So, here’s Merlin – the Uber for Magicians!
The Uber for X solutions all have four common denominators, or strokes of magic if you will. What are they and how magical is my Merlin App idea when it gets validated by them?
In an Uber for X, it must be possible to predict usage and patterns, especially if you rely on a model of contractors instead of employees. Uber (and the other taxi apps) are fantastic examples of a pattern that can be predicted. It’s easy to know that around 5 pm, there will be surge in demand (and price). We won’t know exactly by who, but there will be a guaranteed demand. In other words, the demand consists of predictable patterns on scale, but spontaneity on an individual level.
The Magician market is a pretty stable market too. Birthdays, as one of the probable bread and butter segments, are pretty evenly distributed over time. And mood among the population (at least here in the U.S.) is pretty stable as well. But there will of course be variations in mood (and therefore demand) around big holidays. I’d probably benefit from a market where people are a bit more spontaneous with their urge for magic.
Verdict: Fair to OK.
If you really want to get a high ARPU, it should be a service that you can convince your customers to use more. Again, taxis are great; cheap enough to even make me consider selling my car, to always cab-ride! A lawn mower on-demand, or a hairdresser on-demand… That’s harder. I can only cut the grass so often.
The real question is if people even want that service on-demand? Don’t they want the guy to just ”come around and do his thing every Saturday”? Scheduled, on-time. Applied to my Merlin idea; we’re in the first mover position here, so the app needs to work the market to increase the frequency. People just don’t get how fantastic magic can be for your health – yet.
Many of the on-demand apps are trying to step in and solve the issue of finding a trustworthy supplier. Look at Handy and Task Rabbit for instance. To cover up the lack in frequency, they position themselves as the trusted providers of a range of services, instead of going for one dedicated service, like Uber or Wash.io does. Uber is trying to circumvent taxi medallions that are governed by the city, and Task Rabbit is trying to create a trusted place for the consumer to get stuff done, whatever that might be.
Either way, there is a need for a trusted middle man. People must be prepared to pay premium to have a trusted third party involved. Through all human history, the trader/middle man has been a trusted concept, however constantly threatened by the accusation of not bringing any value into the deal.
Compare Tesla (wanting to sell directly to the consumer instead of going through a dealer), or Dell (their model was to cut out the middle man), with Uber – you simply trust Uber not to rip you off when you enter the cab. For my Merlin app, this means you don’t want the magician to do a disappearing act on you with your money.
One thing Uber does in comparison with, say UPS or a Taxi company, is removing itself from most customer interaction. There’s just an app and an ordered car, that’s it. If there’s a problem; call the driver, not Uber. With a regular taxi company, you’d call dispatch, and the dispatch would call the driver, which would only put a delay on getting the information to the customer. And that sucks.
Direct communication is key for a number of reasons. Customers get to speak to the person that actually has the information they need, and you as an app owner doesn’t have to pay for dispatch. Everyone’s happy! (Almost like a magic trick). Yes, you’d still need customer support, but that would be more of a complaints department, helping customers with the app. And that’s way less frequent than the whole “where are you”-call support.
Now, compare that to trying to track the car with UPS. If you call them, they’ll tell you it’s in this 12-hour window and that no, you can’t call the driver to ask what he thinks or where he is. It’s horrible! That’s why real-time communication is so important in these segments. If you’ve got that, you simply add a call button that dials the phone number of the provider and vice versa.
When enabling real-time communications like voice and SMS, it’s a good idea to help your customers know that their their information private. You, as the trusted middle man, will still have access to your users contact information, but there’s no need for the individual provider to have it. The provider just needs the customer’s first name and a way to contact you. And just as there are crazy providers, there are of course crazy customers too. So, it’s a two-way street where you get to protect both parties, by inserting yourself in the communication flow with dedicated numbers or other solutions.
On top of this, you’ll collect Business Intelligence on how often calls are made or messages are being sent, on durations, where’s and why’s. This is not only useful for product development, but it’s also crucial information to have if there would ever be a dispute between the parties (you can of course also record all the calls for “security and training purposes”). Lastly, you’re getting full control of the communication, and you get to decide when it’s appropriate for them to communicate.
If you go to a company like Sinch that provides communications in mobile apps, there are a few different solutions you can choose to implement.
Phone-to-phone means providing local numbers for your user to dial. The user calls a virtual phone number; the phone number arrives at the supplier, who notifies your backend. Your backend then replies with an action (in this case, calling the suppliers phone); it starts ringing, and they are connected.
Pros: Regular phone networks work even when data connection is poor. Plus, the regular phone screen will be shown especially for iOS.
Cons: Regular phone networks, just as an unknown number for the recipient, can be costly internationally. Also, it brings an out-of-app experience and it lacks meta data.
Pros: It brings an-app experience for the caller, and keeps a high attention for the receiver (since the regular phone is ringing).
Cons: Of course, it’s still an out-of-app experience for the receiving side. Plus, still relatively costly compared to pure VoIP.
Pros and Cons: Same as above but the other way around. This might be a good solution for customer calling suppliers; the supplier can still get meta data about the customer, and it allows for an app screen relevant to this particular on-demand service. Lastly, it’s cheaper than the other way around.
This is where we think it will end up. Pure in-app calling, where you get to control every aspect of the UI and the flow. This will take the unknown out of protecting your user’s identity, and you’ll be able to display who is calling and in what way.
Pros: The possibility to show a lot of meta data and an in-app user experience. App to app is pure VoIP calling (think Skype or Viber), which allows for super cheap calls, super quick call setup, and a super high audio quality.
Cons: On some platforms, you don’t get the full phone notification experience (i.e. Apple).
Verdict: Don’t have it.
I’ve highlighted four characteristics of a successful on-demand app, and Merlin probably won’t last past the initial seed round. I’ve given you some tools to validate your on-demand idea, and some insights to what real-time communication can do for your app. If you have any questions, reach out to @cjsinch or @SinchDev on Twitter, or send me an email at email@example.com.
We will be attending the F8 Facebook Developer Conference from May 1st – 2nd in California, USA. This 2-day event is where developers and businesses explore what’s next in technology and learn about the new products and innovations Facebook is… read more