A few years back I started talking about widgetizing CRM and Enterprise applications. Basically, I suggested that interfaces needed to be designed to help get specific jobs done, and to provide them in the proper context (where we work). I still believe this to be a possible future for CRM and Enterprise applications even though the application vendors seem to prefer an all-or-nothing approach to design. The simple fact for knowledge workers is that they don’t hire an entire CRM application; so why are you forcing them to experience what they don’t use and why are you making them pay for it? As I outlined in Re-inventing CRM for the Customer-centric Organization, an á la carte approach to serving various groups within your customer base makes more sense, and would add more value to the relationship.
There is one more concept I’ve been thinking about for a few years that I would like to add to this picture; replacing data integration with silo bridging. Unlike a grain silo, in the data world we tend to want copies of each silo inside one or more of the other silos. In theory, it allows us to extend our capabilities in one large, clunky user experience with even more data normally found through a separate large and clunky user experience. For example, we are often asked to provide customer financial information (aging, invoices, credit status, etc.) inside the Account record of a CRM application. Certainly, this information can be helpful…in the right context. Historically we’ve had a few options: we could hot swap applications on the desktop (or through terminal services) and risk data manipulation errors by the mere mortals performing them, or we could invest in integration services which would synchronize certain data between front and back office systems.
First, the barrier between front and back office is artificial and has been perpetuated by application vendors who do not see the larger job to be done; or to put it in another way, other jobs related to the job they have focused on. Integrating data this way is wasteful, complicated, expensive and quite often untimely (and inaccurate). However, it has been the best solution available because the problem has not been framed up properly. When it’s convenient to see problems through the lens of a current solution, what we get are generally not the best innovations. Fortunately, there are some extremely innovative ideas and technologies emerging that need to get some serious attention from those they impact most – the customer.
Building Bridges Supports Context
Let’s suppose a knowledge worker communicated with customers primarily through email. Yes, I know, how old fashioned! Secondarily, they follow up by phone and in betwixt all of this they need to gather information from a CRM system, and accounting system. While the company had invested time and money to synchronize data between the accounting system and the CRM system, it was generally lagging and untimely and much of what the worker needed had not been included. On top of that, the worker was required to update information that resided in these two systems. While financial data streamed down, contact information had been ignored, so the worker would need to update that in both systems as new information became available during the course of performing their job.
Oh sure, the company could simply invest more time and money into expanding the integration. But that doesn’t solve the problem today, and it still leaves a portfolio of little problems (duplicative storage, timeliness, etc.). And even then, we haven’t solved the problem of context. This worker spends the day in their email client and must leave this context to find information to bring back to this context. And then they must leave again to make the updates needed in other systems. I see this every day. The pain and frustration is clear. This is a problem that can be solved. We just need to think a little bit different(ly).
I don’t typically mention technology providers by name because I like to be as agnostic as possible and focus on the job we are trying to get done. In this case, I will make an exception. I’ve worked with a platform vendor called SimplyBox for the past few years. They have worked with some large systems integrators; and some software brands actually use their technology to wrap around their own offerings, and you would never know it. They provide a couple of killer capabilities that (almost) completely erase the need for data integration (the old fashioned and expensive way):
- Connectors can be built to any on-premise and/or cloud database or API
- Quickly (seriously quickly) create bi-directional, lightweight HTML/javascript interfaces pulling from, and writing to multiple back end systems in real-time. No more syncing
- Implement these interfaces in any context.
I have had many ideas how best to utilize this platform to build disruptive applications. Seamless and real-time 3rd party data can be embedded within another application, if that’s your context. Bi-direction information can be mashed up from CRM and ERP databases within the context of an email message – in whatever email client you use. If your Window desktop is your context, perhaps a lightweight app to lookup a phone number and record notes from the taskbar is your context (that would be mine!). Your mobile phone might be your context. SimplyBox has recently demonstrated how their technology can be used to bring real-time context to Salesforce.com through Gmail and LinkedIn and they have a free Twitter app for Chrome as well. These are generic examples that should get your imagination into overdrive. This platform has been used for far more powerful and interesting solutions.
In a nutshell, technology such as SimplyBox potentially lays the groundwork for displacing our current vendor provided interfaces; and ultimately their pricing models. If one were to build a portfolio of contextual applications around jobs people are trying to get done, and the situation (or context) they are performing them, it would never matter if the corporate CRM application were replaced, or the accounting system swapped out. The user experience, which was designed from day one to get a job done the most effective way possible, would not necessarily change. Of course, this would ultimately bring into question the need for high cost, elaborate CRM suites, for example. But that’s a battle for a future time. Today, we are just planting the seeds of disruption. There will be more to come.
