The thing is, there are false premise and perception on what software is and what it's worth.
If not for that perception by users, that "there's nobody there just my device, and I have paid for device already, why would not that device 'grow' and become more and more capable, because you know, 'progress'...", then consumers and users would recognise that all software development is done by very clever people who deserve to be paid not less but maybe more than "that nice butcher guy who I go to each week".
Most of casual users have no idea nor interest to understand how much skill and training it takes to build neat useable software. They expect "things just to work".
Moreover, many modern application also require backend servers and associated hosting / hardware renewal and maintenance costs. These are even less visible to the unlearned and untrained eye of the "poi polloi", and building a viable business model has proven to be a choice - or, sometimes, bait-n-switch - between three possibilities:
- Delver for free in order to grow, then sell the company later to an internet whale
- Charge users for usage or for a version of software
- Monetize users (run ads, sell or share user activity data)
At the same time, there's a number of companies still successfully pursuing business model (2), namely Software Subscription.
In this article I would like to offer a novel variant of (2) that might improve its uptake by removing usability barriers and converting the model into a zero-click default with an optional user opt-out.
This can be done with help of fiscal intermediaries; enter Internet Service Providers.
Similarly to how Ebay and Amazon have "gamified" and "1-clicked" the purchase process on their sites, with the "zero-click attention payment" scheme it could be theoretically possible to charge users for usage, even before they have subscribed - provided that all prerequisites of the Architecture are met.
With payments, VISA and MasterCard act as fiscal intermediaries for Ebay.
With the "zero-click attention pay" (ZCAP) scheme I propose, ISP can act in the same way for any service that's compliant and is recognised by the ISP.
What are prerequisites for ZCAP to work?
- ISP keeps an extraneous pool of client's funds in order to be used with ZCAP every month; this can be pre-allocated and limited for client's surety, or post-payment
- Each ZCAP service uses a recognised network protocol that allows network-side observation of Time Spent by the user
- ISP performs network-side observation and real-time charging for used ZCAP services from pre-allocated pool
- Upon the pool exhaustion, ISP may raise a request to allocate another or upgrade the plan
- ISP may charge a percentage of ZCAP for the charging infrastructure support and maintenance
- Users do not need to subscribe to services as long as they have funds in the pool and service is ZCAP-compatible
- ISP may pass relevant user data to ZCAP service in order to identify and authorise the user
- ZCAP services may use standardised _SRV text DNS records to indicate ZCAP support and relevant API locations
What's in it for ISPs?
- higher ARPU
- increased stickiness
- bundling opportunities
What's in it for Subscription-based Services?
- higher usability
- zero-click opt-in
What's in it for the Users?
- potential to avoid user data compromise
- no passwords to remember
- unified billing
- capped billing
- pooled billing (if ZCAP agrees to share the same monthly pool with others)
The diagram for such a scheme follows.
