Skip navigation
All Places > In the News > Blog > Authors ned.canning@vantiv.com

In the News

2 Posts authored by: ned.canning@vantiv.com

vantivone-linkedin-header_nedcanningsheader_2 (1).jpg

Do your customers appreciate all that development effort?

 

cup_of_coffee.JPGI consider myself to be a tech-savvy consumer. When I want to grab a coffee from my favorite chain on the way to work, I pull up the merchant provided app as I start the car. I see my recent orders, and in most cases just re-submit my last purchase. I can get up-to-the-minute information about the stores around me, in case my normal stop is running low on my favorite brand. I place the order, and authenticate payment with a thumbprint as I shift into reverse gear, and set out on the short drive to the coffee shop. When I get there, I check my phone to verify that the order is ready, walk in to the store, greet the clerk, and leave with my cup of brew in a few seconds. The process I just described takes a small army of systems marching in lockstep to pull off. It no doubt took an enormous amount of design, development work, QA & testing. Consider some of the issues that developers had to grapple with:

 

The mobile application needed to communicate with the store’s inventory management system, with a CRM system (to access my profile, preferences and buying history), with Apple Pay or Android Pay to access my payment credentials, and with a payment processor to authorize & process payment. The point-of-sale (POS) system in the coffee shop needed to be able to accept my on-line/eCommerce order and pass it to the barista's queue as it would a regular in-store purchase. The POS needed access to my stored (tokenized) payment credentials, in case I wanted to add some banana bread at the last minute while picking up the coffee.

 

As if this all wasn’t enough, the systems behind the transaction needed my customer details to print out a personalized label that could be used to identify me when I came in to claim my coffee. Trials are already underway with smarter payment systems that pull up a customer’s photo as they walk into the store so that a savvy barista can greet their customer by name and perhaps even wish them a Happy Birthday.

 

Whether too much personalization starts to feel creepy is up for debate, but months of development work and cross-functional teaming no doubt went into this delicate ballet.  Do I appreciate the effort? I haven’t really thought much about it to be honest. I just want my coffee to be ready when I walk in the door. If this shop can't do that, odds are I’ll just find a competitor who can.

 

The lessons for developers & merchants:

Customers may not be familiar with (or care) about things like Tokenization, BLE or Beacons, but they certainly care about convenience, security and good service. Consumers want the buying experience to be simple and seamless. Providing this type of consistent, convenient buying experience requires a high degree of integration between traditionally discrete, channel-specific technologies that merchants have been using for years. The omnicommerce “first movers”, backed by talented IT shops and developers, have set the bar high indeed. Customers might not care about omnichannel, but they certainly know convenience when they see it and are voting with their (increasingly digital) wallets.

 

Developers have a crucial role to play in engineering customer experiences that are as satisfying as the coffee itself!

 

Liked this post? Click "like" at the top to tell us you'd like to see more posts like this.

 

 

To learn more about integrating In-App and web-based buying experiences with your POS, check out our Mobile & Digital Wallet Developer Resources on Vantiv O.N.E.

In payments, strategies for identifying customers are often built around channel-specific tools, technologies, and terminology.  For instance, the term "card-on-file" refers to an eCommerce business' storage of its customer's payment card information, to avoid requiring customers to re-key their credentials when placing subsequent orders.

 

In the brave new world of OmniCommerce however, customers often interact with merchants through multiple channels.  A retailer might recognize a repeat customer by their payment card, whereas an eCommerce provider may rely on an e-mail address. A laundromat might use a phone number to bring up a customer's prior orders and starch preferences.  An attribute useful for identification in one channel, may be unavailable in another.  It’s time for a “re-think” of card-on-file and multi-channel payments, and developers have an important role to play.

 

How Did We Get Here?

 

At one time "In-store" was the only channel available. Over time, merchants devised other channels like mail-order, telephone order.  With the advent of the web, some merchants opened an on-line channel to interact with their customers.  With the proliferation of mobile devices now bringing the shopping experience to the wireless “great outdoors”, the variety of interactions between customers and merchants is increasing dramatically. In-app payments, tap-to-pay, mobile-wallets and beacon technologies are all indicators of this rapid pace of change.

 

The progression of payment options has led to often disconnected, parallel ecosystems of technology and middleware that interact with customers in separate, inconsistent ways. We’re fast approaching a point where growing expectations of customers require that the walls between payment ecosystems be broken down. While it is great to be a consumer in this brave new world, building for multi-channel commerce is clearly a challenge.

 

From “Card-on-File” to “Customer-on-File”

 

Ideally, mobile systems, eCommerce systems, and point-of-sale systems should share a common view of the customer.  All three should be able to recognize an existing customer, allow for the creation a new customer, and all should be able to read or write interaction events associated with a central customer record.

 

This all sounds logical, but creating a composite customer identity can be hard to do in practice.

 

  • Customers on mobile devices may not have the patience to key-in a lot of data, and merchants may be reluctant to ask lest they inhibit sales
  • In-store customers may not want to volunteer personal information like e-mail addresses and phone numbers
  • Customers often use throw away yahoo or gmail accounts for on-line interactions to avoid receiving nuisance e-mail on their primary e-mail accounts

 

Data veracity is an ongoing challenge. People move, phone numbers change, cards expire, devices get swapped out, and data entry errors are common.

 

Flexible, Extensible Schemas

 

A customer database that can serve multi-channel commerce needs to tolerate some level of “fuziness”.  It may not be possible to populate all customer attributes with just one or a few transactions.  It may take several interactions before identity can be “federated” and transactions previously viewed as discrete can be recognized as belonging to the same customer.

 

The database schema that underlies this type of “customer-on-file” functionality needs to be flexible and easily extensible.  Merchants will almost certainly have a need to capture and store additional attributes in future including new types of tokens, credentials from new authentication services, or digital signatures from devices not invented yet.

In an age where the cost of storage is plummeting, and the cost of data acquisition (for digital transactions at least) is approaching free, a good practice is to store everything you can just in case you need it in future.  This includes contact info, payment credentials (secured, of course), and customer device info; anything related to a customer that identifies them and how they interact with various touchpoints is of value.

How Customer-on-File Helps the Business

 

Creating a single, cross-channel customer identity provides value at several stages in the merchant – customer relationship.

 

Acquisition phase

 

The acquisition phase is where you need to build your customer database. All payment channels should access a common database to:

 

  1. Identify if a customer is new or existing
  2. Append to a customer's record with as many attributes as possible.

 

If a customer is in a retail shop, they could be incented to sign up for an email list by providing their email address, or providing their phone number and first/last name.  If a customer phones into a customer service center, they could provide their mailing address or phone number. If a customer browses your website, store as much as you can including browser information, the IP addresses, and any unique device ID.  The more information attached to the customer record, the better.

 

Conversion

 

The conversion phase is where a centralized customer view starts to show value. When a customer is ready to buy, the merchant can demonstrate how attentive they’ve been during the acquisition stage.

Buy-online-pick-up-in-store is a powerful tool for retail and food service merchants, but requires online/offline systems to be able to quickly access customer details for efficient identification and fulfillment. Similar scenarios - buy-online-ship-from-store, buy-in-store-ship-from-warehouse, split shipments - all help to ensure successful conversion, but all depend on quick and easy access to a customer-centric system.

 

Developers should think about how to design systems that are flexible enough to “set the table” for the next interaction, but avoid introducing friction into the conversion process.  On the eCommerce channel a fraud service provider like Threatmetrix can pass your web-application additional “telemetry” and device signature information helping you more easily identify a device if it enters your ecosystem in the future.

 

Retention / Up-sell

 

The retention and upsell phase is where a customer-centric data strategy can really pay off for merchants.  Effective identification of an existing customer will increase loyalty and boost the lifetime value of the customer relationship.  Is the customer returning a website purchase to a retail location?  The store should be able to grab the payment credentials from the eCommerce system, process the refund, and e-mail a confirmation.  Is the customer buying a pair of shorts at an outlet store?  Your system should ideally present the customer’s cross-channel buying history, and identify cross-sell / up-sell opportunities.

 

How Do We Get There?

 

For developers, enabling these smart, customer-centric buying experiences starts with a common customer database.  The key is to build deliberately, and assume that there will always be new channels that your customers will use to reach you.  There will be specific idiosyncrasies to adapt to with each new channel, but a customer-on-file database remains central of them all.

 

Building a solution on a technology platform focused on a single channel runs the risk of creating a patchwork of services that will be difficult and costly to maintain and integrate.

 

To help facilitate this “customer-on-file” design principle, selecting payment providers that are channel agnostic will pay dividends in future.  It will make it easier and more cost effective to support new channels and technologies, and it will increase the value of your solution to the merchants you serve.

 

Did you like this post? Click "like" at the top to tell us to make more content like this.