Telcos, this is how users want to pay for mobile data…

After the long, circular, and confusing discussion on Twitter this evening around what the hell we’re paying for and getting when we chose a data plan for a mobile device, I think it’s time for a clean slate outline of how I, and I think others would like to purchase mobile data.

1. Forget everything you know about your existing plans. Customers really have no idea what they’re paying for, even if you sit down and try to work it out, they’re overly complex.

2. Forget about calendar month billing cycles, everyone hates this scheme. (Except for maybe accountants, but they’re ‘unique’ individuals)

3. Given the premium price mobile data carries, users want to know that they’re going to be able to use every single last megabyte they pay for. NO MATTER WHAT. They don’t want to have to worry about megabytes expiring.

4. Given the proliferation of secondary mobile devices such as the iPad and… uhh… well yeah, the iPad, people don’t want to be contracted to use a certain amount of data every single month. They want to purchase it when they need it, and have it just work.

So with those points in mind, what should mobile data plans look like? It’s really simple.

Offer users say five or so different purchase volumes:

250MB  for $v

500MB for $w

1GB for $x

5GB for $y

10GB for $z

Set a SINGLE long expiry time across all of the volume breaks (somewhere in the 3 to 6 month range) The expiry always starts from the date the data block was purchase (not confusing calendar month expiry). Long enough for it to not be a concern that the data block will expire before it’s totally used up, but short enough so that heavy users can still benefit from volume pricing. For all intents and purposes, users shouldn’t have to worry about data expiring, they just purchase more when they run out.

First to implement this plan wins.

Layton

29 notes

Show

  1. supply reblogged this from laytonduncan
  2. stuartm reblogged this from laytonduncan
  3. chiefie reblogged this from laytonduncan
  4. robotexplosion reblogged this from laytonduncan
  5. laytonduncan posted this