Some time ago I saw a competitor’s video for a mobile app experience. In the story, a parent has ‘shared’ some SMS messages with a child, and the child’s SMS balance runs out. Using the app, the child requests some more SMS from their parent, and the parent’s app notifies and allows them to satisfy the request.
The experience itself was reasonably well executed and I think a realistic kind of scenario. In fact, I was reminded of this video only recently, when I witnessed a real world example of this while cycling with a friend. As we approached the crest of a hill, he received a text from his US network advising his data plan had hit 80%, and as it was only one week into his billing period we had to stop for him to take action. On this occasion the action was phoning his daughter and asking her to stop watching videos – there was no app to help him – and this blunt self-serve approach reminded me of the real-world constraints when sharing today.
Although the competitor’s video looked compelling, being the technologist I couldn’t help dissecting what was really going on. You see, by moving some SMS into the kid’s account, they were ‘sharing’ in a sense, and in the consumer view of things it certainly serves a purpose. But it’s not sharing in the true form. Inviting someone to dinner I typically serve food in the middle of the table and allow my guests to help themselves. The SMS ‘sharing’ approach was more analogous to handing out single loaded forks, one at a time, and asking the guests to repeatedly ask for more. Or if you prefer, I could pile up everyone’s plates equally, and risk one guest still being hungry while another can’t finish their helping – it’s never polite to ask for food from someone else’s plate! This is the key difference between ‘transferring’ and ‘sharing’, even if they look nearly the same to the untrained eye.
We have the ‘shared dinner plate in the middle of the table’ model, where everyone helps themselves, first come first served.
The flexibility of our platform at MATRIXX means we tend to see sharing use cases in all the varied forms. We have the ‘single fork at a time’ transfer model, as described in the video, where balances are manually shuffled around, and the owner has explicit control. Fiddly account management, but simple to understand the user experience. This is one of the easier to implement although you still need to think about how the shared assets revenue will be recognized, as technically it has been transferred to another account.
We have the ‘shared dinner plate in the middle of the table’ model, where everyone helps themselves, first come first served. That model is incredibly powerful and tends to stress the less performant software platforms; but you also need to consider the user experience can be challenging to get right, especially when you introduce user level credit limits.
Do you show everyone the main shared bucket, or do you show individual tailored views that are based on only what is available to them? And how do you show that something they had available to them has already been ‘eaten’ by someone else? I have personally witnessed numerous whiteboards filled out in the pursuit of solving that one.
We also see lighter dynamic scenarios like loaning and gifting. There is no permanent relationship in these cases and one subscriber can simply send something to another subscriber; it could be some minutes, data or even a product purchased on their behalf. In many ways, this is easier to build and requires less database heavy lifting, but under the covers there are hidden “gotchas” and business logic complexities to discuss. How will gifting some Pre-paid minutes affect the validity date of the original asset – does the date go with the gift? Do you transfer the revenue recognition to the recipient as part of GL processing? What if the recipient transitioned to a credit control state while the gift was being made?
We have customers that want to give their unused assets to charity. We have customers that want to share their excess with looser communities of subscribers. We have some customers who join groups dynamically and all contribute individual amounts into a collective pot. I honestly haven’t even thought about revenue recognition on that last one – one for the accountants.
In short, enabling a generous subscriber base in telecoms is surprisingly complicated, but certainly rewarding.