Pages

Pages

Wednesday, May 08, 2013

An RCS use-case I'd actually support & see as viable

It's now more than 2.5 years since my publication of a report on "RCS is Dead" in September 2010. While RCS has shambled on as an undead Zombie technology since then, and we've still got a few lonely operators kicking over its rotting corpse at the moment, I thought I should reflect on a couple of points I'd mentioned.

I maintain my position that there is zero benefit - and quite a lot of cost - to RCS (either the general version or the Joyn-branded GSMA-approved one) as a standalone app. The contention that it will somehow encourage people to give up using WhatsApp, KakaoTalk, Line and the other messaging platforms is risible. Worse, expounding the notion that RCS might sway people away from using embedded messaging capability in apps such as Facebook should be grounds for firing someone for gross incompetence. Blending it in with VoLTE will further delay and complicate an already-struggling (and much more important) system - the two should be kept 100% separate until either/both are well-established.

In my 2010 report, I suggested that one way to salvage something from the wreckage of RCS was for operators to offer fully-OTT versions of the app or API. MetroPCS is fairly close to that, announcing a related capability at MWC . I  also suggested that operators consider using RCS for their own customer-service and self-care function, and mandating their own employees to use it for IM (not eating your own dogfood is never a good sign). A fourth option was using RCS within operator-branded vertical-community apps, perhaps for sports or movies or home-automation.

In many ways, the GSMA Joyn branding, which has to be paid for (!!!!) by operators wishing to subjugate any hope of differentiation, has made matters a lot worse. It just highlights the fact that it is a clumsy multi-operator service that has little value until 80%+ of a given population can use it. (For MetroPCS, it's perhaps not so bad as it's the only RCS player of any sort in North America at present, so it has the logo to itself for now at least).

Overall, I see no grounds for a general-purpose, cross-operator standardised messaging app. Pointing to SMS as a success "proving" federated standards are worthwhile, ignores 20 years of innovation on the web, smartphones, cloud and apps in the meantime. Standalone Joyn is worse than useless, sucking up money and resources that could be better used by operators on design and innovation, or partnering with Internet/app providers who "get it".

I've got more sympathy - to a limited extent - for RCS as an API, or with various forms of web mashup which might create new messaging experiences and user-interaction models. Because the web integration would likely be single-carrier, ideally offered on an OTT basis rather than federated across multiple telcos, there is a chance to differentiate and make some money. (I'm not going to cover WebRTC integration here, which I address that in quite a lot of depth in my recent report ).

But in the spirit of my original report, I've actually thought through a variant of RCS which I'd actually be prepared to support, and even use myself if it worked well. Yes, you read that correctly.

For *some* of my messaging interactions, it would be useful to have a common-denominator app that's better than SMS and more convenient than email. I've thought of a version I'd actually be prepared to use.

I hate unsolicited SMS and spam emails with a vengeance. I want any future messaging services to be white-list capable, with sophisticated controls and policies. I'm not convinced that Facebook or Twitter - if they ever released an open messaging API - would be in a position to control their advertisers to the extent I'd like.

So, thinking about my "perfect generic messaging app", I want something which is able to:

- accept inbound messages from my Facebook & LinkedIn contacts only (including groups & events, not just people, but excluding brand pages). I want that configurable so I can add/drop other social services - and subsets of affiliations within them - in the future.
- accept inbound messages from people in my handset addressbook (these days, that's far fewer than FB & LI contacts - I rarely take peoples' phone numbers).
- charge £5 a time for inbound messages from unknown people or organisations, based on a combination of number + social connections. I'll even give a rev-share on this! (There's your new business model, telcos, protecting my privacy and acting as my "interruption agency").
- give me the ability to refund the fee if I want (eg a friend loses their phone & contacts me from someone else's, or a prospective client gets in touch)
- have a "report as spam" and "block" button, which also (& quite specifically) will block all marketing messages from my service provider if I choose
- has a sensible price structure - maybe not quite as cheap as WhatsApp, but £5-10 a year flat is reasonable, excluding the value-adds like the pay-to-interrupt feature. No international or roaming premiums
- has a good UI and features that evolve on a monthly basis
- Service is offered on a fully-OTT basis, usable from all my devices, irrespective of connection method. I want it to work on my PC without installing an application, via the web with a password login (or FB / LI / Twitter authentication)
- Decoupled from SIM and mobile phone number, using a separate identifier range, so there is no need to "port" it if I switch access providers, and it works easily when I travel and use a local SIM in a spare phone
- Integration with my preferred voice applications (eg click-to-speak/call), especially Skype at the moment, but maybe WebRTC ones in future too.
- A good / clever UI. Facebook's new "chat-heads" is fantastic
- Doesn't do anything creepy in terms of "big data" through analysis of my social graph / usage patterns
- EDIT: Doesn't kill my battery with clunky presence / always-on implementations. (Hat-tip to Kevin Holley on Twitter for that!) Whatsapp's"last seen online" is probably the best current version of presence, rather than online/offline/busy which nobody uses properly.

Anyone prepared to step up for that? Is it easier to do with RCS, or does that add little to the solution? For me, the "no unwanted interruptions" feature is critical, as is "report as spam".

Standalone, and pitched as some unconvincing "SMS 2.0" or direct clone of Whatsapp, RCS & Joyn are worse than useless. But if you can use it to create something unique that improves the user-interaction model, then I'm willing to listen.

(Sidenote: in the past 6 months, my worst SMS spam offenders have been the UK's pestilential PPI-refund lawyers, my own operator Vodafone UK, and the GSMA sending me unsolicited nonsense about MWC).

3 comments:

  1. Dean,
    Most of the things your propose are feasible with current technology or additional simple features.
    Use non e164 based identities is considered in the RCS spec. Also both, server sider or client side can implement the white-label mechanishm you would like to have. Also it is possible to bridge between 3rd party exposure of RCS and SNs, in fact we do that.

    Regarding the business models you propose can make sense but others can make sense too.

    In the past we see how advertisement funded MVNOs failed, perhaps because no way to address the proper ad-message to the proper individual in the right timing.

    RCS would allow to have this business for your segments, and use geolocation push to say the ad-server where you are and be given vouchers or discounts in the zone nearby. This could be done with the network API but you need some base of users using joyn/RCS even in parallel with Whatsapp or others.

    Also, people not using RCS for personal communications could have or install as service hub with info services, CRMs, content uploaders, etc...it would be a phonebook of "services" as alternative to the individual apps for each individual case model. The problem is that companies (we have feedback about it) like to communicate with their customers in the same way that people connect between them (it happens also in Twitter & FB).
    Then, sharing the common messaging experience (chat, FT... standard or ott, chat it chat) for P2P, A2P, M2P reduces the "learning entry barrier" to create new services.

    Technology is like plastiline, some times and the real barrier is not the limitations of the technology itself but the self-imposed own cage by telco execs.

    ReplyDelete
  2. Dean,

    I am missing something here - the way you defined this service, I can implement it today and launch it as pure OTT.
    Where's the value of a telco offering it instead of an OTT?

    ReplyDelete
  3. Juan: Thanks for your comment. Glad to hear this is mostly feasible. I'm not especially convinced by a "phonebook of services" though, unless the UI is very clear indeed.

    Tsahi: *cough*..... yes, I know. But hey, RCS is all about competing with OTTs, so if the operators & vendors reckon they've got the platform to do it faster/cheaper/better, then go for it...

    ReplyDelete