On-Demand CRM at "feature level"

Leandro Goldberg,
Contributing Blogger/CRM Advisor

It's time to talk about the concept of on-demand and how completely over used this phrase has become in nearly every aspect of technology. Let's talk about CRM, where on-demand seems to thrash between vendors perhaps more competitively than any other areas.

The concept was initially introduced to showcase the ability for things to happen "seamlessly" in the most broad sense through automation driven by integrated software and hardware technology platforms. One of the very first "on demand" commercials showed a Ferrari getting painted the color of your choice with a simple touch of the stylus. Impressive, highly unlikely, but a good example of how to catch one's attention and make a legitimate point at the same time.

On-demand capabilities are taking an interesting twist by refining the initial concept of demand itself and taking it to a much more discrete approach by servicing the demand on a per-feature basis within application deployments.

For example, older technology deployments of CRM used technology that resulted in large-scale mammoth systems that required consulting intervention to make discrete features work for specific situations. This model, although not completely gone has certainly been replaced with applications that are infinitely more agile. Why do we need this?

Business systems today require a much broader-based enablement that is often sliced and diced based on roles and responsibilities. Why should you pay for expensive consulting to turn on a feature that might be necessary a handful of times? The value proposition diminishes quickly if you have to pump dollars to bend the technology that you shoud have probably gotten in the first place.

Tracking as a CRM concept is perhaps the core component that is common among all of the business functions (support, sales, lead generation, etc.). Not all users of the tracking portion of CRM are created equal, since today, much of the tracking information is (and should be) available to outside constituents for communication and relationship building. That said, certainly some portion of the information that is tracked (for example) in a service request should be blocked from external consumption (such as a customer or business partner). With larger systems, you can be certain that the ability to hide that information is done through complex custom coding or expensive vendor intervention.

Another critical component to consider for buyers of on-demand at a "feature level" is a discrimminating appetite for component-based, "flat technology" that inherently provides the capability to morph functionality literally by customer request. Such designs offer two major benefits:

• architecture that enables quick modifications and fast deployment
• functionality that provides dedicated features notwithstanding a shared environment (such as hosting)

In all fairness, many vendors have graduated to the fast deployment model, since CRM disasters of the past were most notably related to deployment times, resulting in budget overages and lost time-to-market. By the same token however, some vendors (which will remain nameless) are still operating under the mammoth model, with greater than 70% of their deployments deemed unsuccessful for just these reasons.

Perhaps the more compelling business requirement today is the capability for vendors to support customized deployments that deviate from standard code maintenance as we have come to know it. The traditional model says one build and deployment is good for everyone - hardly the model for today's on-demand environments, where feature requirements are as a la carte as the pumpkin pie you can pick from any dessert tray. In other words, today's CRM providers need to meet specific vendor needs and still maintain an infrastructure that does not wrap their technical staff around the software axel, so-to-speak.

When considering CRM architectures, specifically in hosted environments, on-demand concepts lend themselves well to the following characteristics:

• pick a vendor that can support your customized requests despite a shared hosting environment - ask the question first before taking the plunge
• look for a vendor that will give you the database if you exit their service, with an option to buy on-premise licensing. This ensures a flexible schema and your ability to easily support that model going forward
• Look for flexibility - make sure the solution you pick is roles-based with plenty of ability to turn discrete features on and off for particular areas of functionality by profile.
• Ask what technology and database vendors are used and be certain you can support an on-premise path for the future, both with engineers that know the technology and database support.

Leandro Goldberg



Email: lgoldberg@supportfusion.com
Comany: Support Fusion Inc.
Blog: supportfusion.blogspot.com