A Few More UX Hacks

February 16th, 2018

In continuation of my previous post entitled A Few UX Hacks, here are a few more UX hacks.

#4. MERCURY READER

Problem: While they’re not cluttered, some webpages display their content across the entire width of the screen. Reading these webpages can strain the eyes.

Solution:

Mercury Reader again!

Apart from stripping off distracting elements off a webpage, the aforementioned Chrome Extension renders the core content in a narrow window. This eliminates eye strain.

To check it out, take Nick Szabo’s white paper on Smart Contracts. When the man who is hailed to be the “quiet master of cryptocurrency” and rumored to be creator of Bitcoin published his epic work in 1996, responsive design was not a thing and there was perhaps no way to control the zoom width of text on a webpage. As a result, the white paper is very difficult to read at its original location in its full screen form. I managed to go through it only after I used Mercury Reader. Have a look at the BEFORE and AFTER views below and you’ll get what I mean (Exhibit 6).

Exhibit 6

While Mercury Reader removed the eye strain of reading the white paper, it couldn’t prevent it from boggling the mind, but that’s another problem!

#5. NOOK COLOR

Problem: You swipe right to go to the next page on a Nook Color. But, sometimes, you might get stuck on the same page or even be taken back a page or two after executing this action.

I think this is because a typical Nook Color is never switched off. From personal experience and anecdotal evidence, most people keep the world’s second largest selling eBook Reader – next only to Amazon Kindle – on even when they’re not using it. As a result, I suspect the Adobe Reader Mobile software used to open eBooks on the Nook Color freezes up from time to time, which I attribute as the root cause of this problem.

Solution:

No, no, I won’t tell you to switch off your Nook Color – after all, its tagline is “Read Forever”!

Let’s say you’re on page 11 and want to go to page 12 when you face this problem. I suggest the following steps to make progress:

Exhibit 7

  1. Short tap the power button on the upper LHS of the device. The screen will go dark. Wait for a few seconds and then short tap this button again. The screen will light up. Once you swipe out the lockscreen and swipe right on your current page, you should be able to reach the next page. If this doesn’t work
  2. Tap the page, tap the GO to PAGE button on the bottom RHS of the page (Exhibit 7), enter the page number of the next page (i.e. 12), and tap the GO button. This should take you to the next page. If this too doesn’t work
  3. Repeat #2 but enter the page number of the next to next page (i.e. 13). This will take you one page ahead of your desired page. Simply swipe left to reach the previous page, which is where you wanted to go.

In the 100+ eBooks I must have read on my Nook Color, this problem has never gone unsolved beyond the third step.

#ProTip: If you Nook Color’s charger blows, you can find a simple solution in my blog post entitled Panic Not If Your Nook Color Charger Blows.


I hope you find these hacks useful.

If you have any UX hacks of your own, please share them in the comments. Thanks in advance.

PayTM Shows How #FeatureOrBug Can Drain Trust

February 9th, 2018

As we saw in Feature Or Bug – Facebook & Tideplus, #FeatureOrBug refers to a feature that masquerades as a bug.

To recap:

As brands increasingly adopt personalization in their communications, what you see is not what I see.

Then there are other types of differences like:

  1. What you see on desktop is not what you see on mobile
  2. What you see yesterday is not what you see today
  3. Inconsistencies in what you see wherever and whenever.

At first blush, it might seem that the discrepancy is caused by a bug in brand websites, apps or messages. But, if we dig deep, we might get the nagging feeling that the brand has deliberately caused the difference i.e. the discrepancy is actually a feature.

In that post and in the follow-on one entitled Feature Or Bug – Housing, LinkedIn, Starbucks, Et Al, I covered many favorable and neutral examples of #FeatureOrBug from Facebook, LinkedIn, Starbucks, and a few more brands.

In this post, I’ll discuss an unfavorable case of #FeatureOrBug.


Frequent users of PayTM will be aware that there are three ways of making a payment with India’s leading e-wallet:

  • Method 1: Pay with credit card and other funding sources on file. This method requires two-factor authentication according to the Indian regulator’s mandate. But, by letting you store a card on file, PayTM obviates the need to enter credit card details for each and every transaction. Therefore, the 2FA involved in this step entails less friction and lower risk of failed payments compared to the way most other brands dumbly implement 2FA “as per RBI mandate”
  • Method 2: Pay with wallet balance. To use this method, you need to top up your PayTM wallet with funds from your credit / debit card, bank account (or other PayTM users). This step does not require 2FA – or even 1FA.

  • Method 3: In case you initiate a payment via Method 2 without having enough balance in your wallet to cover your bill, PayTM automatically invokes Method 1, lets you cover the shortfall in-flight from your funding sources on file, and complete your payment in a single pass.

PayTM lets users choose their desired method of payment through the Fast Forward option located above the Proceed to Pay Bill button. Users can leave the option unchecked to let the payment proceed via Method 1. Or they can check Fast Forward to opt for Method 2. (As noted earlier, Method 3 is system-invoked).

Since I don’t like to block my money in “yet another e-wallet”, I opt for Method 1 whenever I use PayTM to pay my utility, phone and other bills. Ergo, I never check the Fast Forward option.

(#ProTip: If you pay your utility bill directly on your utility company’s website with your credit card, you might be slapped with a Surcharge. Instead, if you use PayTM to pay the same bill with the same credit card, PayTM will eat the credit card processing cost. Not only will it not levy any surcharge, PayTM might even give you a cashback. The double benefit is a form of what’s commonly called “VC Subsidy”. In addition, you might find PayTM’s UX better.)

There’s one exception to my overwhelming preference for Method 1: Uber. When #CurrencySwitch caused a huge cash crunch a little over a year ago, I’d to go cashless for my taxi rides. At the time, the only cashless payment method supported by Uber was PayTM wallet balance and I’d to live with it. Since then, I’ve been keeping some balance in my PayTM wallet to pay for my Uber rides via Method 2.

I recently headed over to PayTM to pay a mobile phone bill. As usual, I opted for Method 1 and left the Fast Forward option unchecked. I clicked the Proceed to Pay Bill button and kept my credit card CVV and VbV password handy. However, this time, the website didn’t ask me to enter these two pieces of information. Instead, it made the payment from my wallet balance i.e. PayTM used Method 2.

In short, I opted for Method 1 but PayTM overrode my preference and used Method 2.

I asked PayTM Customer Care if this was a Feature or Bug.

PayTM CC claimed that I must have checked the Fast Forward option, that’s why PayTM took money out of my wallet. I countered its claim by producing the following screenshot.

PayTM CC then came back with a different explanation saying that, as long as there’s enough balance in the wallet for a payment, the company had initiated a new practice of pulling money out from the wallet regardless of whether the customer has checked the Fast Forward option or not. So this was a Feature, not a Bug as it appeared at first blush.

In effect, PayTM told me, “we will take the money from your wallet even if you don’t want us to touch your wallet.”

Now, that’s called pickpocketing in plain English.

PayTM justified its use of Method 2 on the grounds that it expedites the transaction. Since Method 2 does not require 2FA – or even 1FA – it does expedite the payment.

But it’s still pickpocketing, just carried out electronically.

I see no difference between PayTM and a supermarket cashier who ignores your request to pay by credit card and pulls out cash from your leather wallet under the pretext of expediting the checkout process.

And PayTM’s patronizing assurance “you can always add money to your wallet” is like the aforementioned cashier telling you, “You can withdraw money from the ATM outside the store to replenish your leather wallet with cash”.

After this incident, I started wondering, if PayTM fools around with my wallet today, what will it do with my cards on file tomorrow.


As noted in my previous post, since any #FeatureOrBug is introduced by the brand owner, it must favor the brand.

I got thinking about how this specific #FeatureOrBug benefits PayTM.

I could think of the following possibilities:

  1. PayTM acts as the Merchant of Record in Method 1 and incurs MDR cost, which is reportedly 1.5%. Since it doesn’t slap any surcharge on the payer, PayTM eats this cost. The company avoids this cost by resorting to Method 2
  2. Monies loaded on PayTM wallets didn’t earn any interest in the past. Now, they do: Wallet balances have been moved to the newly created PayTM Payments Bank and, like other banks, PayTM pays interest on them. In Method 2, PayTM exhausts wallet balances faster and thereby reduces its interest burden
  3. By skipping a trip to the credit card rails in the case of Method 2, PayTM uses less computing power and bandwidth, and hence incurs lower infrastructure cost.

All benefits of Method 2 to PayTM are related to lower costs.

Amidst pressures from its investors to reduce its mounting losses, the VC-funded PayTM is justified in taking steps to cut costs.

But not picking pockets.

I think a better approach would be for PayTM to remove the Fast Forward option and make it clear that it supported only one method of payment i.e. Method 2. I can then decide whether to “take it or leave it”.

But, to give me the choice and flagrantly violate it is a breach of trust.

As a result, I began weaning away from PayTM – I now use it only to encash the aforementioned “VC Subsidy”.


Regular readers of this blog would be familiar with my frequent rants about the friction and poor CX in banking, not to mention the nickel-and-diming resorted to by banks from time to time.

However, not once during the course of my dealing with over a dozen banks in half a dozen countries in over three decades have I doubted the integrity of a single bank. (Knock on wood!)

With PayTM, that happened with a single transaction.

Thanks to this incident, I found out that Uber India has changed its method for accepting credit card payments. While the novel workflow complies with the regulator’s 2FA mandate, it considerably reduces the friction caused by having to fiddle around with CVV / VbV / OTP at the end of a taxi ride. Soon after making this discovery, I switched the default payment mode on my Uber app to Credit Card from Paytm.

If there’s a lesson in this for PayTM and all other fintechs, it’s the old saying about how trust is hard to gain but easy to lose.

Flight Delay Insurance – Why Blockchain?

February 2nd, 2018

I covered two Blockchain flight delay insurance products in AXA Fizzy – The New Kid On The Blockchain and Atlas Etherisc – Another New Kid On The Blockchain.

In this post, I’ll address the “Why Blockchain?” question.

Here’s a quick recap of the background to this question from the first post:

…the techie in me started wondering what stopped someone from developing a similar flight delay insurance product on a traditional centralized database architecture… Is there any intrinsic shortcoming with a centralized database architecture that compels one to launch this product only on the distributed database architecture facilitated by Blockchain?

I’ll first examine what AXA Fizzy and Atlas Etherisc say on the subject and then share my thoughts.

Given below is an extract from the FAQ section of AXA Fizzy’s website:

FAQ: Why does Fizzy use Blockchain technology?

When you purchase a policy, fizzy writes the transaction terms (price, compensation, expected time of arrival, arrival time to trigger compensation…) on a blockchain called Ethereum. The interest of the blockchain is the inability to remove previously-written transactions. What’s more, the Ethereum Blockchain is public, any crypto developer can therefore check the validity of the information we store there. fizzy doesn’t ask you to trust it, rather proves it through trustful processes. Last thing, we never share your personal information on Ethereum, your data is safe with us.

FAQ: What if I don’t agree with the delay reported by fizzy?

fizzy is based on redundant data which enables us to trust its reliability. Besides, as we are a party to your insurance transaction, we made sure that the payment of your compensation is not decided by fizzy but directly by the plane data provider. You don’t have to trust our honesty! In spite of these measures, you can contact us through the contact tab in case of any problem. You can also find here information on the EU Online Dispute Resolution: http://ec.europa.eu/odr

I didn’t find any justification on Atlas Etherisc’s website for its decision to use Blockchain.

Addressing the potential buyer of its insurance product, AXA Fizzy’s replies emphasize Trustlessness, which is one of the two low-hanging fruits for a Blockchain decentralized app (Robustness being the other).

As one such prospective customer, here’s what I think about AXA’s replies:

  • I need to trust fizzy to write the transaction terms on the Ethereum Blockchain. Going by my experience with Atlas Etherisc, this is a non-trivial step
  • The Ethereum Blockchain was rolled back after DAO hack. Therefore, I don’t agree with fizzy’s claim that previous transactions are immutable on the Blockchain. While it could be argued that hard forks leading to rollbacks are very rare in the Blockchain world, point is, when they do happen, they’re driven unilaterally by a very few people who resemble a secret cabal in which the average Joe / Joanne Customer has no say
  • An average air traveler is not a cryptodeveloper, so it’s not very useful to know that “any crypto developer can therefore check the validity of the information we store there”
  • I may not need to trust AXA after fizzy has written the transaction on the Blockchain but I still do need to trust its Flight Data Provider (whoever it is).

Prima facie, the claim of trustlessness lacks depth.

The shallowness of the trustlessness value proposition is reinforced when I compare these two insurance dApps with a conventional insurance product running on a centralized database architecture (herewith “cApp”):

  • Once I buy the policy, I get a policy document. I can take a printout to prove the transaction in case the Insurer tries to change it later. Besides, in my experience of buying dozens of insurance policies in four countries over three decades, not a single insurer has ever changed the terms of the policy after issuing it (not saying they won’t in future, though)
  • I don’t need to be a cryptodeveloper to understand the basic terms of the policy. Even an average air traveler can understand parameters like price, compensation, expected time of arrival, arrival time to trigger compensation (of course, even a cryptodeveloper won’t be able to understand the fineprint of an insurance policy).

I know Blockchain is evolving. But, at this juncture, it’s hard to accept that either of the two flight delay insurance dApps I’ve encountered exhibits trustlessness.

And I’m not alone. As btcethereumadmin says here:

“Even an open-source project like Bitcoin that is constantly being reviewed can have trust issues, not from the code but by the developers and reviewers of the code. So trustlessness is more of a term describing an ideal state on the blockchain where code is law with the caveat that humans write code and to err is human.”

And to forgive is not divine – at least not to IT services companies who make tons of money from SIT, UAT and other testing phases of a software project!

Technology is full of X-less movements e.g. ebilling drives paperless billing; digital payments drives cashless societies; and digital channels drives branchless banking. Most of them have failed at their X-less mission. But they’ve created an X-less outcome e.g. less paper, less cash and less branch in the case of ebilling, digital payments and digital channels respectively.

I was about to conclude that Blockchain is another such movement that will begin with trustless and end with lesstrust.

That changed when I saw the following screen on the Atlas Etherisc website.

Yes, you saw that right: Stamp duty for a Smart Contract!

Stamp duty comes into picture while registering an agreement with a government authority. When a Smart Contract attracts stamp duty, it belies the claim that Blockchain helps two parties conduct business without an intermediary. It appears that Blockchain insurance policies issued by Atlas Etherisc do have an intermediary, namely, the government of Malta.

Based on this experience, a smart contract not only calls for trust in technology but also requires the blessings of a government.

This suggests that Blockchain demands more trust than a centralized application.

I know this sounds like a sacrilege to Blockchain purists, so I’m bracing myself for a few brickbats from them in the comments!


Let’s move on to Robustness, the second raison d’être for Blockchain dApps.

To ensure high availability of its centralized app, a company

  1. Needs to hire DBAs to provision access rights to ensure integrity of content of central database (this is apart from having to buy server, operating system and database software)
  2. Set up ACTIVE:ACTIVE clustering to provide redundancy / fault tolerance
  3. Invest in secondary disaster recovery site for business continuity.

All of this costs a lot of money in manpower, cybersecurity tools and real estate.

I’m sure that every insurance company spends money on DBAs and cybersecurity tools to run its current cApps. However, I strongly doubt if many of them will be able to justify the high costs of #2 and #3 for a relatively low-ticket flight delay insurance system. I say this on the basis of my following experience:

  • A leading financial institution couldn’t find a strong enough business case for investing in ACTIVE:ACTIVE infrastructure even for a high value payment system
  • When floods once struck the English town in which a bank’s primary datacenter was located, I quizzed the CIO about his bank’s Business Continuity Plan. He quipped, “Mops and buckets”!

Contrast this with a Blockchain dApp. Transactions are cryptographically locked down and distributed across multiple nodes. As a result, a dApp is inherently shielded from data breaches and intrinsically enjoys extreme fault tolerance. More on this in “Blockchains vs Centralized Databases”, an excellent article from Gideon Greenspan of Multichain.

In a nutshell, you get a highly robust application on the Blockchain virtually free-of-cost. (Actually virtually free only of fixed cost. Variable cost in the form of Gas Price does apply for dApps. But that’s a story for another day.)


AXA Fizzy spins its choice of Blockchain as a customer benefit by emphasizing trustlessness. (I didn’t see any spiel for Blockchain on Atlas Etherisc’s website.)

I don’t buy it.

Based on my limited knowledge and experience on the subject, I think the real reason to opt for a decentralized Blockchain architecture over a centralized database architecture is Robustness, or more specifically, lower cost of achieving robustness.

That’s not a bad thing.

Lower cost is a benefit for insurance providers but higher robustness is a customer benefit.

This was driven home for the nth time when I had to link my insurance policies to my Aadhaar Number (per government mandate). All the three times I visited my insurer’s website to carry out the so-called “Aadhaar seeding”, the website was down.

It struck me that, if only the insurance company had used the Blockchain for its insurance applications, it would have delivered 24*7*365 operations at no cost and delivered superior CX compared to a traditional centralized database architecture.

Feature Or Bug – Housing, LinkedIn, Starbucks, Et Al

January 26th, 2018

In Feature Or Bug – Facebook & Tideplus, we saw two cases of #FeatureOrBug, one of which was favorable to the consumer, and the other, neutral.

I’ve subsequently come across many more favorable / neutral cases of #FeatureOrBug. I thought I’ll cover them before fulfilling the promise I made at the end of the last post to write about an unfavorable #FeatureOrBug.

Here goes the second installment of my #FeatureOrBug list (For the sake of continuity, I’m appending it to the list given in my previous post.)

#3. HOUSING.COM LISTING

I listed my apartment on Housing.com around six months ago. A month later, it was rented out. I informed the company accordingly. However, it has still not pulled down my listing.

On the face of it, this could appear to be a Bug caused by oversight or apathy.

But, on second thoughts, by letting my listing stay, Housing earns extra pageviews and, thus, additional advertising revenues. So, this could be a Feature.

But, it’s a shortsighted feature, at best. Because the portal loses credibility by making people waste their time pursuing expired listings.

It also goes against the charter of Housing.com. As I highlighted in Can Something Be Too Frictionless?, the startup founded by a bunch of my alumni from IIT Bombay differentiated itself from the other real estate portals of that era by being obsessed over data quality. Knowing fully well that prospective tenants and buyers get turned off by pursuing an apartment that has already been rented / sold, Housing.com would actively follow up with landlords to inquire whether their apartment was still available and made it very easy for landlords to take down a listing by simply giving a “missed call”. That way, the company made sure that the data on its portal was always refreshed and valid.

That was then.

Now the company doesn’t seem to care about the quality of data.

For old times sake, I’m doing its job by sending an email to everyone who contacts me, informing them that my apartment has been rented out and tipping them off to other rentable properties in the same housing complex.

#4. LINKEDIN SEND INVITE

Inviters are prompted to add a personal note while sending an invite on the desktop version of LinkedIn. In the mobile app version of LinkedIn, this prompt is missing.

On first blush, this might appear to be a Bug with the mobile version, as it does to member Dr Aniruddha Malpani:

Ketharaman Swaminathan yes, this is a major bug which LinkedIn needs to fix!

But, on closer examination, this could be a Feature.

Let me explain why.

In its early days, LinkedIn set the following three conditions for sending an Invite:

  1. Send Invites only to people you know
  2. State your relationship with the Invitee
  3. Add a personal note to your Invite.

Over time, LinkedIn dropped the first condition. You could send Invites to anyone in your second or third degree network.

Then it dropped the second condition. You no longer had to select options like “did business together” and “studied in same school / college” to amplify your relationship with the Invitee.

Now, it has made the personal note optional.

On the desktop version of LinkedIn, you see the following screen while sending an Invite.

You can add a personal note by clicking the Add a note button but you can also skip it by clicking the Send now button. Notice also how the Send now button is the highlighted option. On the mobile app, you don’t even see the Add a note button in the regular workflow – it appears only if you tap the menu button.

The trend is clear. LinkedIn has gradually reduced the friction of the Send Invite feature over the years. This has enhanced the UX for Inviters, especially the raising number of whom that access the application from mobile devices, which has in turn increased the number of Invites Sent and boosted the conversion rate of Visitors to Invites Sent. Both metrics add pageviews and drive additional advertising revenues for LinkedIn.

On the Invitee’s side, the current way of working of the Send Invite feature has created a greater volume of Invites Received and a higher percentage of Invites without personal notes. Invitees respond in one of the following three ways:

  1. They feel highly wanted because they get so many Invites and accept all of them without further thought. Both the volume of Invites Accepted and conversion rate of Invites Received to Accepted goes up
  2. They ignore all Invites lacking a personal note. Both the volume of Invites Accepted and conversion rate of Invites Received to Accepted goes down
  3. They click through to the profile of the Inviter and otherwise put in the extra efforts to decide whether to accept the Invite or not.

Case 1 is favorable to LinkedIn. Case 2 is unfavorable to LinkedIn. It’s difficult to predict the impact of Case 3.

Only LinkedIn knows the frequency of occurrence of these three cases and, accordingly, whether this is a Feature or Bug. (Based on personal observation, I’ll bet that Case 1 outnumbers 2 and 3 hollow and, that, therefore, this is a Feature).

#5. STARBUCKS NAME MISSPELLING

Starbucks misspells my name regularly. With a name like mine, Starbucks is not the only one. So I shrug it off as a Bug.

But, according to Mental Floss, “Starbucks misspells names on purpose”. According to a team that confirmed this hypothesis by using a very common name (Molly), “The more ridiculous the botched name, the more likely consumers are to share a photo on social media.” Since free publicity is a benefit, misspelling names is likely a Feature.

#6. ANGEL INVESTMENTS GOING DOWN

According to Times of India, startups are struggling to raise funds in a year when availability of VC funding reached an all-time high. This may appear to be a Bug to a lay person.

But, as I highlighted in When A Business Is VC Funded, VC Is The Business, risk capital is invested across many distinct stages. Depending upon market conditions, some stages could be flush with funds whereas others could be starved of funds – at the same time. So, this is clearly a Feature of the VC investment model.

#7. MISCELLANEOUS

Here are a few more examples of #FeatureOrBug – without my explanatory remarks. I’ll leave it to readers to crack them.

 

 

 


Before I conclude, let me share one instance of #FeatureOrBug that boggles my mind.

In the same email, Quora tells me that someone has upvoted my answer but reports 0 upvotes for my answer.

 

This is a Bug for an old company that has many legacy systems. Like my bank in Germany. If I had a balance of €1000 and withdrew €200 from its ATM, the ATM’s display would continue to show a balance of €1000 even after it dispensed the cash. My correct balance of €800 would be shown only in the paper statement that spewed out of the statement printing machine kept adjacent to the ATM. Apparently, the ATM switch was refreshed by a mainframe batch job running at midnight whereas the statement printing machine got the balance data in realtime from another system. Ergo Bug, and one that can’t be fixed so easily.

But Quora is a new-age Internet company. It shouldn’t be using any legacy systems. Then why does it demonstrate an issue that appears to be a Bug? Even 20 year old Indian banks never exhibited the kind of discrepancy that my German bank did.

Or is this really a Feature masquerading as a Bug for reasons that I’m unable to fathom?

I know Quora is the best place to ask questions but I’m not sure if it allows self-referential questions!

So I’m turning to my readers.

If any of you has a clue about what’s happening here, please share your thoughts in the comments below.

Atlas Etherisc – Another New Kid On The Blockchain

January 19th, 2018

At the end of my blog post entitled AXA Fizzy – The New Kid On The Blockchain, I’d promised to answer the “Why Blockchain?” question in a follow-on post.

I’m not fulfilling that promise yet.

Frequent readers of this blog would be aware that it’s light on research and heavy on personal experience and anecdotal evidence.

For reasons highlighted in my previous post, I couldn’t – and still can’t – buy an AXA Fizzy insurance policy. Nor could I find anyone else who has bought one. Without personal experience or anecdotal evidence, I found it hard to deep-dive into the “Why Blockchain?” subject. Since writing a post entirely on the basis of desktop research is not my style, I was about to can my follow-on post.

Until I found another Blockchain flight delay insurance product that I could “test drive” a couple of weeks ago.

This is from an unnamed company whose website features a origami bird as its logo but lacks any other branding. According to the fineprint on the homepage, it’s powered by one etherisc.com, whose website says it’s a provider of “decentralized insurance”.

I’d actually stumbled onto this website soon after I heard about AXA Fizzy. At the time, it allowed purchase of flight delay insurance on many sectors, including BOM and DEL airports in India – unlike AXA Fizzy, which offers policies only on flights to and from CDG. However, it accepted only ETH payments.

I went and signed up with a cryptoexchange and set up my cryptowallet. I then returned to this website, only to find that it now offered policies only on flights in and out of SFO. So, once again, I couldn’t buy insurance on a sector originating from BOM or DEL in India.

On this visit to the website, I saw an addition to the fineprint: The website said its policies were issued by one Atlas Insurance PCC Limited, an insurance company based out of Malta. Absent any brand name on the website, I’ll refer to this product / company as “Atlas Etherisc” going forward.

A few days after publishing AXA Fizzy – The New Kid On The Blockchain, I happened to visit Atlas Etherisc’s website again. This time, it offered insurance on BOM / DEL sectors and accepted fiat currency payments in USD / EUR / GBP. I decided to apply for a policy for the BOM-FRA sector on Lufthansa LH757 flight. The premium and payouts are shown in Exhibit 1.

Exhibit 1

When I entered my credit card details to make the US$ 17 payment and hit the “Apply” button, the website went into a tizzy and displayed a message saying “Waiting for transaction to be mined” (see Exhibit 2).

Exhibit 2

I guess that was the process of writing the transaction on the Blockchain.

This message was still there after five hours. (Now I get why system architects recommend centralized database if performance is key.)

I don’t know whether Atlas issued a policy in my name or successfully registered the transaction on the Blockchain.


I now have personal experience on an insurance dApp. I hope to get some anecdotal evidence about dApps in the coming days. In the meanwhile, I also gained some more experience on a conventional insurance website.

Thanks to all this, I feel adequately geared up to deep dive into the “centralized versus decentralized app” subject and finally fulfill my promise to write that elusive follow-on post on the “Why Blockchain?” question. (Spoiler Alert: We’ll see another example of Hiding Your Secret Sauce.)

Stay tuned!

Is There Any Indian App To Store Your Indian Loyalty Cards Digitally?

January 12th, 2018

I recently read the following question on Quora:

Is there any app that helps to store all your loyalty cards digitally?

I am looking for an app which is India based or atleast caters to the Indian market.

Someone once said that, on Quora, you answer the question that’s asked, the question that’s not asked, and the question that should be asked.

When I read this question, my first reaction was to wax eloquent about an Indian app that stores all loyalty cards in the world digitally. After doing a quick reality check, I felt that was a bit of wishful thinking and decided to restrict myself to the question that was asked.

Given below is a lightly edited version of my answer.


What the OP is asking for is a “mobile loyalty wallet”, an app that lets consumers scan their plastic loyalty cards into their smartphone. By digitizing physical cards, a mobile loyalty wallet saves consumers the trouble of having to carry all their physical cards in their wallets and ensures that they never lose out on rewards when they shop at a store whose loyalty card they’ve forgotten to carry with them. A mobile loyalty wallet shouldn’t be confused with “mobile wallet”, which stores credit and debit cards digitally and is used to make payments with a mobile device.

I’m a happy user of KeyRing app for several years. The maker of this app gives its location as Dallas, TX, in the USA.

Apple Wallet (previously known as Passbook) is another similar app. It’s also Made in USA.

From time to time, I’ve come across a couple of Indian mobile loyalty wallets when their founders reached out to me seeking angel investment. I’ve forgotten their names. All I can remember about them is that, their UX uniformly sucked and I deleted them within a week. When they sought my feedback, I referred their founders to KeyRing and Apple Wallet as a source of inspiration for making their apps more frictionless. Like founders of most Indian startups – barring the ones founded by IITians – they ignored my feedback and tried to teach me how to hold the camera while scanning the card and many other things I now forget. At this point, I don’t have any Indian mobile loyalty wallets to recommend.

But that shouldn’t matter. Because, regardless of its country of origin, a mobile loyalty wallet app lets you digitize your loyalty cards from any country by simply scanning the barcode on the card or, if the card doesn’t have a barcode, by clicking a picture of the front and back of the card.

Like I’ve onboarded the loyalty card of the Indian QSR chain Mast Kalandar on my American KeyRing app.

From there on, whenever you’re shopping, you reach the checkout, fire up the app, select the said retailer’s card and flash your smartphone screen at the retailer’s POS machine (iOS Passport does all this automatically, probably based on LBS technology). If the retailer has the technology to scan the digital card off of your smartphone screen, you’d have extracted the full value from your mobile loyalty wallet. If not, you’d need to read out the card number manually and the checkout clerk would need to enter it manually into their POS system. In this case, you wouldn’t have used the full capability of your mobile loyalty wallet.

In the several years that I’ve been using KeyRing, I haven’t come across a single retailer in India who can scan the card from the smartphone. As a result, I’ve never been able to put my mobile loyalty wallet to full use in India.

This is not only true of KeyRing and Apple Wallet but also of all the Indian mobile loyalty wallets I’ve deleted.


Over time, the very mobile loyalty wallet category has lost its shine in India – thank God I didn’t invest in any of them! That’s because retailers have increasingly started using the customer’s mobile phone number as a proxy for the loyalty program member ID. While many retailers continue to issue plastic loyalty cards, that’s largely for branding purposes.

The way it works at many stores now, customers finish their shopping, reach checkout, and earn points by verbally quoting their mobile phone # to the billing clerk. There’s no need to show the plastic card and hence no need for a mobile loyalty wallet to earn points.

Many retailers also permit customers to redeem their points by speaking out their mobile phone # at checkout. So even redemption does not require the plastic card or mobile loyalty wallet. The few security-conscious retailers that insist on the plastic card for redemption won’t anyway be able to accept a mobile loyalty wallet because they can only scan the magstripe on the physical card.

Therefore, the usage frequency of plastic loyalty cards – and the value proposition of a mobile loyalty wallet – have dropped drastically in recent times in India.


People share their mobile phone numbers freely in India. Since the OP’s question pertained to India, I could conveniently assume that a retailer can get the customer’s mobile phone number and substitute it for loyalty program member ID.

In a global context, this assumption is not valid. Consumers don’t disclose their mobile phone numbers that freely in USA, UK and many other countries. Loyalty membership numbers embossed on plastic loyalty cards are still required to earn and redeem reward points – retailers can’t replace them so easily with mobile phone numbers. Ergo, the value proposition of mobile loyalty wallet is still intact in those markets.

AXA Fizzy – The New Kid On The Blockchain

January 5th, 2018

I’ve been asked many times to write about my Blockchain experience. That is not strictly true. I’ve been asked only twice, most recently by a man in Mumbai, Maharashtra.

How can I write about the Blockchain experience, I asked myself on the Deccan Queen returning to Pune, when most of the founders of the Blockchain companies are too busy writing white papers and running ICOs to develop their dApps and the few of them that have launched their dApps are too daunted by their UIs to let anyone other than their Blockchain programmers use them?

 

(Fans of Joseph Heller might find a striking resemblance between the above paragraphs and the opening paragraphs of Good As Gold, one of my all time favorite novels. I apologize in advance to the Estate of Heller for taking the liberty of paraphrasing what’s one of the most captivating novel starts that I’ve ever read.)

All that changed when I read about AXA Fizzy on Finextra a couple of months ago.

Fizzy is a blockchain-based “parametric insurance” product that pays out compensation for flights delayed beyond two hours. It’s already live – you can buy a policy right now if you have a valid ticket on a CDG-USA sector (or so it says on the website – as an ex-Frankfurt resident and Lufthansa Miles & More member, I’m more likely to transit to the US via FRA, which will exclude me from the target audience of the product that’s currently available only for flights to and from CDG).

I was stunned when I first first heard of AXA Fizzy.

Let me explain why.

When I lived in Frankfurt, I’d booked a holiday to Paris for my family. Memory serves, it was via Expedia.de. While making the booking, I’d forgotten to uncheck the box next to “Kaufen Reiseversicherung” (buy travel insurance). As a result, I’d unwittingly bought travel insurance. As luck would have it, a day before we were to fly out, one of my family members had a stomach upset. We had to cancel the trip. I thanked my stars for thrusting travel insurance upon me and assumed that, now that Expedia was alerted of my cancellation, it’d process my refund of airfare and hotel charges automatically.

How naive I was.

The process to claim my insured money back was highly cumbersome.

First, there was the question of eligibility. Like any insurance product, Expedia’s travel insurance policy also came with its own list of inclusions (items covered under the policy) and exclusions (items not covered under the policy). It’s hard enough to understand insurance fineprint in English. It was virtually impossible to do it with my then level of proficiency in German. Thankfully, there were many native German-speaking coworkers in my office. I could take their help in combing through the German-language insurance contract and ascertain that the reason for my cancellation was indeed included in the policy – under the “serious illness of one of the travelers” risk.

Then came the claim procedure. I had to write a justification for my cancellation in German and attach a medical certificate from an Expedia-empanelled doctor certifying that my family member was too ill to travel.

When I got past that, I faced a few more hurdles that I don’t recall now, since all of this happened nearly 15 years ago.

Long story short, I had to jump through so many hoops to get my money back that I vowed to myself that I’d never buy travel insurance again. And never did in the following decade and a half.

But I might break my promise because of AXA Fizzy.

The way it works, AXA Fizzy checks flight arrival times published in the public domain (FlightStats.com, if my guess is right). If the flight is delayed by two hours or more, it automatically pays out the predetermined compensation to the credit card used to buy the insurance.

AXA Fizzy doesn’t make claim process frictionless. It eliminates it altogether.

It doesn’t have any exclusions. As its website says, “NO EXCLUSION: We cover you, whatever the cause of your delay : Snow, strike,”… even “alien attack…”!

With these key differentiators, AXA Fizzy raises the appeal of travel insurance to the next level, which could potentially create a manifold increase in the size of the market for travel insurance products. Especially after it expands worldwide this year and adds flight cancellation, lost baggage and other travel-related products to its portfolio of offerings.

Ergo AXA Fizzy is stunning.

Now, that’s the marketer in me talking.

Then the techie in me started wondering what stopped someone from developing a similar flight delay insurance product on a traditional centralized database architecture (as against the decentralized Blockchain architecture used by AXA Fizzy).

I took this up on Finextra by posing the following question:

On a side note, can anyone throw some light on the dependency of such an insurance product on Blockchain. Is there any intrinsic shortcoming with a centralized database architecture that compels one to launch this product only on the distributed database architecture facilitated by Blockchain?

I didn’t get any reply.

I forgot about my question until I read “Blockchains vs Centralized Databases”. In this article, author Gideon Greenspan of MultiChain compares the traditional centralized database architecture with the decentralized database Blockchain architecture and asserts that whatever you can do on a Blockchain you can also do on a centralized database. “In terms of the types of data that can be stored, and the transactions that can be performed on that data, blockchains don’t do anything new.”, he adds.

After reading this, my question started haunting me whenever I read anything about Blockchain and dApps. I couldn’t ignore it anymore and raised it on a few other forums.

I started getting replies from a few Blockchain pioneers, including a detailed one from Gjermund Bjaanes, author of a brilliant article titled Understanding Ethereum Smart Contracts.

The overall takeaway from my interactions with all of them is:

  • If you need Confidentiality and Performance, select Centralized Database.
  • If you need Trustlessness and Robustness, go for Blockchain.

In a follow on post, I’ll share my thoughts on how these general guidelines play out in the specific context of a B2C product like AXA Fizzy. Watch this space!

Meanwhile, please feel free to share your thoughts in the comments below.

Season’s Greetings!

January 1st, 2018

Season’s Greetings and Best Wishes for a Joyous New Year 2018.

Welcome back to GTM360 Blog!

We’re happy to inform readers that 2017 was a blockbuster year, with a near doubling of traffic and an all- time high level of engagement via comments and one-on-one feedback.

Here’s the list of Top 10 Most Popular Posts on GTM360 Blog in 2017:

#10. Quantifying The Risk Of Online Payment Failure

#9. Why Branch And Digital Channels Will Coexist Forever

#8. How To Fight Card Payment Surcharge And Take #CashlessIndia To Next Level

#7. Uber Creates Loyalty To The Deal But Not For The Brand

#6. Reliance Jio – All Good Things Don’t Come To An End, They Just Stop Being Free

#5. Why Social Media Has Become My First Port Of Call For Customer Service

#4. How Relevant Is “Crossing The Chasm” After 25 Years?

#3. Mastering Targeted Offers – The Uber Way

#2. Why COD Still Rules Ecommerce In India

And the most popular post of 2017 was:

#1. Five Reasons Why PayTM Is Miles Ahead Of Its Competition

GTM360 Blog stands on the pillars of WordPress, PowerPoint, IrfanView, Pixel Ruler, etc. Our heartfelt gratitude to these applications.

We thank you for your continued interest in GTM360 and look forward to deepening our engagement with you in 2018.

Feature Or Bug – Facebook & Tideplus

December 22nd, 2017

Uber has been making targeted offers for a long time. As I highlighted in my post titled Mastering Targeted Offers – The Uber Way, some people get an offer, others don’t. As a result, two cohorts of riders can see two different prices for the same ride. In the early days, the price difference was attributed to a bug. But, as customers learned that Uber makes targeted offers at the level of individual riders, they began to recognize the disparity for the feature that it really is.

As brands increasingly adopt personalization in their communications, what you see is not what I see. At first blush, it might seem that the difference is caused by a bug in brand websites, apps or messages. But, if we dig deep, we might start getting the feeling that the discrepancy is perhaps driven by a conscious action taken by the brand i.e. feature.

This post is about “what you see is not what I see” or what I call #FeatureOrBug.

Since #FeatureOrBug is introduced by the brand owner, it obviously favors the brand. As we’ll soon see, it increases engagement, decreases cost, pumps up sales and delivers other benefits to the brand owner.

As for the consumer, there are three degrees of #FeatureOrBug:

  1. Favorable
  2. Neutral
  3. Unfavorable

Consumers will probably like a first degree #FeatureOrBug. Therefore, it boosts customer loyalty.

Consumers are indifferent to a second degree #FeatureOrBug. In the worst case, they may be somewhat ticked off by it. But it still won’t affect their engagement with the brand in the future. Accordingly, a second degree #FeatureOrBug is neutral to customer loyalty.

Consumers are antagonized by a third degree #FeatureOrBug. As a result, it adversely impacts customer loyalty.

In this post, I’ll illustrate the three degrees of #FeatureOrBug with one example of each.

#1. FACEBOOK CHECKIN – Favorable #FeatureOrBug

I saw the following update on my Facebook Feed.

If you notice the text carefully, it reads “Vikesh Mehta was drinking having breakfast…”.

Wot? Drinking breakfast?

Tongue in cheek, I replied, “I’ve heard of “liquid lunch”. Now “liquid” has started from breakfast itself, eh?:)”.

My friend thought it was a bug, reasoning that FB had tagged the said eatery as a coffee shop, thus forcing the status to begin with “drinking”.

I wasn’t so sure.

I’ve seen many such Facebook updates in the past. I didn’t know they were called FB Checkin and I’ve never reacted to one before. Both of that changed after I read this update. By displaying it in the manner that it did on this occasion, Facebook created awareness and generated engagement for Checkin. Ergo, it was probably a feature rather than a bug. Since I was happy to learn about a new Facebook “product”, this #FeatureOrBug was favorable to me.

#2. TIDEPLUS – Neutral #FeatureOrBug

The leading detergent brand TIDEplus recently ran a promo. You had to locate a code on the product’s pouch and enter it on PayTM’s website to earn a cashback on your PayTM wallet.

It was hard to find the code. But I located it finally on the inner surface of the detergent’s pouch.

I entered the code on PayTM’s website, only to be informed that the offer had already expired.

I naturally felt shortchanged.

I inferred one of the following two things from this exercise:

  • TIDEplus expected to sell a certain number of products on offer (“offer packs”) during the offer period and shipped that quantity to the trade. But actual sales were lower than expected. As a result, many offer packs were still left on the shelves – one of which was the one I’d purchased. In an ideal world, a company would go back to the trade and recall all unsold offer packs. But, in the real world, I don’t know a single corporate paragon of virtue that does that and I don’t expect P&G, the owner of TIDEplus, to be the exception.

OR

  • TIDEplus deliberately dumped more offer packs than it expected to sell during the offer period, hoping to capitalize on the strong possibility that the offer would attract a lot of additional consumers out of which only a few would bother to redeem it and fewer still would complain when they found out that the offer had expired by then. This is a shady practice. Notwithstanding the number of brands who follow it – and there are many – this practice tarnishes the brand image.

Since I’d no way of knowing which of the two things had really happened, I gave the benefit of doubt to the brand. While I’m now a little wary of TIDEplus, I’m not upset that badly that I’ll stop buying the product in future.

On a side note, sophisticated CEM solutions are now available that help brands estimate in advance how much sales uplift they can get by running a certain customer engagement program. One of our customers has such a solution. Brand managers who need help in this space can feel free to contact us.


The next installment of this post will feature a third degree #FeatureOrBug.

Spoiler Alert: Some #FeatureOrBug shenanigans can turn a brand advocate to an ex-customer.

Watch this space!

Lessons For Marketing From Spectacular Comeback Of QR Codes Via Mobile Payments

December 15th, 2017

It’s still raining QR codes!

All leading mobile payment products in the world use QR codes. This includes Alipay and WeChat Pay in China, PayTM and PayZapp in India and Starbucks App in the United States.

QR code has been popular in China for the last 4-5 years.

In India, the nineties-era technology has become very visible in the last one year, driven by its use in leading digital payment products that got a huge stimulus on the back of the demonetization of high value currency notes a little over a year ago.

I often joke that QR code would easily qualify for “Graphic of the Year Award”, if such a category existed.

As regular readers of this blog would know, I’ve been tracking QR codes in advertising and allied areas for many years. The caption of the above picture is an obvious reference to this post I wrote four years ago on the ubiquity of QR codes in newspapers, magazines, posters and billboards.

I continued with that pursuit by checking out around ten QR codes in print and outdoor ads over the last twelve months.

Each of them ticked the following three basic boxes:

  1. Scans on a wide range of smartphone cameras
  2. Drives a natural transition from print / online / TV to mobile
  3. Microsite is mobile-optimized

A couple of them went further and supported the following advanced features:

  1. CTA can be conveniently performed on a smartphone
  2. CTA exploits the power of the smartphone

This is a huge improvement over QR codes of the past that would fail to scan or lead to non mobile-optimized websites.

I wish I could say the same thing about their engagement levels. Let me explain that with the following three examples.

#1. BAJAJALLIANZ (Print Ad)

The leading private sector insurer of India published a QR code in a newspaper ad that occupied a prominent spot at the top of the page.

The CTA for the QR code was “Scan this QR code to know why term plans are a must have”.

The ad was dated 12 December 2016, which was four days after #CurrencySwitch happened. The visibility of QR code had already jumped up.

However, the QR code on this ad received only one scan (probably mine!).

#2. SAP (Print Ad)

The world’s largest enterprise software company gave a gentle reminder about GST in a newspaper ad and added a QR code for more information. For the uninitiated, GST stands for “Goods and Services Tax”, which was introduced in India last July.

Despite the fact that the ad occupied a full page, the QR code in it received only one scan (again probably mine!).

#3. SPLASH (Outdoor Sign)

Splash, the Zara of Middle East, has a floor-to-ceiling QR code at the entrance to its store in a large mall.

Despite the fact that this huge QR code has been around for several years in a high footfall area, it has received only double-digit scans.


Scan volumes of QR codes are low uniformly across print and outdoor ads in both B2C and B2B realms.

Traditionally, the tepid response to QR code has been attributed to low awareness of the technology. That factor is no longer applicable. Thanks to the widespread use of the technology in digital payments, QR code has virtually become a household name in the last 1-2 years.

Why, then, are QR codes still receiving lukewarm reception in advertising?

IMO, it’s because of the context in which they’re used.

QR code works very well when it forms an integral part of a workflow i.e. it’s used to do something, like completing a mobile payment transaction. However, it does not work so well when it’s used as the source of advertising information.

Does it mean marketers should stop using QR codes?

Not at all.

But it does suggest that they should find ways to use them differently. Instead of attaching them to ads, posters and billboards as a passive information resource, marketers can multiply the effectiveness of QR codes by inserting them into advertising and marketing CTAs. The sweepstake workflow is one case in point. There are other compelling use cases of QR codes in our QR360 Framework (PDF 730KB).

The spectacular comeback of QR code via mobile payments has validated the basic value proposition of the technology and pointed the way to where it works best. Advertisers and marketers are now well set to deploy them in the right context in order to drive engagement, improve conversion rates and get more bang for the marketing buck.