The Price of Everything

Great companies take charge of the entire problem, soup to nuts. 

Our payroll provider takes care of a thousand little details, from making the right deductions to filing reports with the government to direct deposit.  And we’re happy to pay for this - they solve our entire payroll problem.

Customers pay for the simplest, best method to get results.  They look at their total problem, not just the piece we happen to cover.  If you want happy customers, look at the whole problem too.

Here’s one example from our business: data feeds.

Our software runs amazing analytics, outputs useful reports, and makes customers lots of money.  But it can’t do anything in a vacuum.  The program needs information from the bank about past depositor behavior.

This data comes from the bank’s core deposit system, in the form of massive text feeds.  Very specific data, like interest rates and balances.  Most enterprise software works this way. 

Somewhere during implementation, the IT department becomes responsible for providing input data.  And that’s where the snags begin. 

Every bank’s IT department is overwhelmed.  Whether they are recovering from converting to a new core system, integrating the latest merged bank’s IT, or simply struggling to deal with all of their various info requests, life is tough.  And by the time the database guru builds a data feed, they have moved on and don’t want to hear about problems you found in the first attempt.  Even on a critical project.

There are two ways to handle this:

1. Make the customer responsible for putting clean data into the system.  After all, it’s their data.
2. Accept clean data as our problem too.  After all, our customer is not the IT staffer, it is the CFO or Head of Retail.  They want results, regardless of what happens in the IT department.  Customers are not paying to convert great data feeds into better pricing - they are buying better pricing.

As a user working in a bank, I’ve hit software built on the first approach.  I had to work intensively with the IT department over months to develop data feeds that were approximately correct.  Many quirks in our data were not documented well, so neither me or the IT guys knew what we would get until we built the feed and laboriously examined it.  Eventually, I figured out some problems in the feed and scheduled another revision to be built by IT.

We believe in the second philosophy here.

1. Straightforward data specifications - fields are clearly described, marked as mandatory or optional, and are consistent.
2. Import errors based on domain knowledge - many problems raise red flags to experienced bankers.  Whether it’s a negative CD balance, a DDA account with a non-zero interest rate, or hundreds of other issues.  The software finds the problem, labels the issue in a way that makes sense to a banker, and provides a default solution.
3. Excel review - feeds with hundreds of thousands of records are displayed in Excel.  Problems are displayed in red, with error messages attached.  Errors are summarized in a cover worksheet with full search capability.  Plus, you can use Excel’s native capabilities, like filtering and sorting, to examine the feed more deeply.
4. Flexible data feeds - fields can come in any order, delimited or laid out in columns.  This comes in handy for customers that already built similar data feeds for asset liability management, MCIF systems, or other banking applications.
5. Formulas - all excel formulas are allowed, including lookup.  This is a lifesaver when data entry clerks have found six different ways to spell “Business Checking” and the original data can’t be corrected.  We relied on Excel’s formulas to get massive functionality, without introducing bugs or extra documentation.  Microsoft has already made this work for millions of users.
6. Client Services - here’s where experience with hundreds of implementations really pays off.  Randa knows where different data is found in the bank, how hard it is to get, and can think of workarounds when needed.  Her goal is to help avoid trips back to the IT department - and she’s very good at it.  She can often successfully implement with flawed data and move forward.  The customer is notified about flaws in the data feed, but the process doesn’t grind to a halt.  After implementation, the customer is responsible for dealing with new data problems, but knows exactly how to proceed.
7. Default import setup - each customer can make changes, knowing they can click a button and reset their import setup to what was delivered at implementation.

In our case, worrying about data feeds means quicker implementations and avoiding a lot of bad data.  This starts off the customer relationship on the right footing.  Almost as important, we don’t root through code to solve problems caused by bad data.

Think about the whole problem you are solving for the customer.  The more pain you can take away from them, the better.  Not only does your product grow in value, but you avoid tsuris (Yiddish for “pain in the tuchis”) downstream too.

Bookmark to: