In Why Overcoming The Tyranny Of Excel Is A Lousy Positioning Theme, we’d cautioned software companies from pitching their software as a replacement for Excel.
Since then, we’re happy to see more innovative positioning around Excel by technology providers. For example, BI vendor Domo pitches its suite of data visualization products as complementary to – not substitute for – Excel.
— GTM360 (@GTM360) June 24, 2014
Kudos to Domo, even if we say so ourselves!
In this blog post, we’ll cover another disturbing trend in software: Telling the customer to use Excel before they can use the software.
This was a common practice in the mid 1990s when ERP vendors used to circulate Excel-based “Master Data Collection Forms” for collecting bulk data like customer master, item master, vendor master, and so on. We’re dismayed that, despite the availability of far more advanced technology 20 years later, vendors in many product categories still use Excel sheets for the same purpose.
There are at least two reasons why this is not a good thing:
#1. COGNITIVE DISSONANCE
You’ve just bought a software after listening to a vendor tell you how it’s better than Excel (among other things). Then you’re told to use Excel before you can use the software. If you’re like most customers, you’d feel let down badly, or undergo what’s called “cognitive dissonance” in Consumer Behavior.
In the days of onprem software, enterprises were committed to the success of the implementation because they’d paid the license fee for the software upfront, so software companies didn’t have to bother too much about cognitive dissonance. However, in the SAAS world, a customer that suffers from cognitive dissonance is a customer that’s likely to cancel their subscription by the end of the month. So cognitive dissonance has become a critical issue now.
#2. ONBOARDING FAILURE
Excel is error-prone. In almost every onboarding we’ve seen, Excel uploads have eventually led to poor data quality, incorrect classification of hierarchical entities and additional efforts for reconciling Excel-inputted data with “true” data. In some cases, errors in Excel have caused catastrophes, as highlighted by GTNews in “The Perils of Excel”: “Elementary spreadsheet errors have in this case potentially impacted the economic well-being of perhaps billions of people, who have been exposed to austerity policies based upon false data.”
This threatens onboarding and, thus stymies revenues of a SAAS company.
It’s therefore clear why software companies should eschew the use of Excel for collecting master data.
But that’s easier said than done, given the widespread usage of the practice. Before we propose a solution for this apparent conundrum, we need to understand why Excel is so popular in the first place.
- In Excel, you can enter data at high speed from the keyboard. In software frontend, you need to look at the screen and use the mouse. This slows you down.
- After entering a row in Excel, it’s easy to hit the Enter key to go to the next row immediately. On a software frontend, you need to hit the Submit button at the end of a screen and wait for the screen to be refreshed and the next blank screen to come up.
- Excel accepts anything. Software throws out errors when its validation logic spots a discrepancy between the data entered and the field definition. For some fields, software allows you to only select entries from a drop-down box. If you can’t find your data on the list, you’re stuck.
In short, Excel is faster for bulk data entry and does not ground you with fatal errors.
Against this backdrop, any alternative for Excel should address these fundamental issues.
The key to doing so is the realization that screens in software are designed for entering small amounts of transaction data over a long period of time rather than for entering huge amounts of master data over a short duration. Using the same screen for onboarding causes all the problems that have established Excel’s predominant position in the process of collecting master data.
To address this, we recommend development of a separate set of screens that mimics the way Excel works in gathering bulk data. Each screen should allow entry of data without validation, which should be run on a batch of data instead of when each screen is saved, as most software products do today. In other words, validation should happen “offline” instead of “online” as in the current design. The same error queues and messages used for validating Excel-inputted data should be reused for validating data entered via frontend screens. This will ensure that master data can be inputted using the software as easily and with equal – if not better – quality as via Excel.
We admit that development of this separate “Onboarding UI” will increase development efforts. But it will also eliminate cognitive dissonance and minimize onboarding failures. From the experience of a customer that has followed this approach in their software, the incremental efforts will pay back many times over by reducing churn and enhancing CX over the lifetime of the SAAS software.