Kevin, buddy, nice well-reasoned post. Unfortunately your arguments, while compelling, are not persuasive. Since my friends all tell me what a pain I am, allow me to live up to my reputation and give some counter-arguments. (Whoomi is a lot more tolerant).
...Support organization business methodology is much more mature and standard than SFA...
That cuts both ways. Support business processes are well-understood, and the majority of support transactions are routine. Automation to the routine parts of the business adds value. Support personnel are trained in the routine ways of doing business (which allows companies to cut support costs by using cheap labor). Exceptions are escalated to more senior people; for these people the automation tools add little value. My point is, there is a 'culture of process' in support organizations.
You say the word 'process' to salespeople and watch them gag. Many salespeople are still used to operating as loners. 'Team-selling' is a great concept, but few organizations have a disciplined enough salesforce that actually logs events and is willing to share information, an essential pre-requisite for team selling. For this reason, I believe SFA is more difficult because the tools must be invisible and seamlessly fit into the existing salesforce culture. Nobody has done this yet, which is why the simple tools are still the rage in SFA. For example, contact managers are the most successful elements of SFA--salespeople need and use address books all the time. Proposal generators save time having to type up the same stuff over and over again. Other tools have varying degrees of usefulness to the salesforce (as distinct from sales management). When was the last time you saw a salesperson drool over a 'forecasting tool' the way you can see a support person drool over a 'problem resolution system'?
As you say, the expectation in support apps is for a HUGE (sorry, Mr. Siebel) minimum required functionality. This functionality is pretty much understood and scoped out. It is a lot of work to design and code the support apps and make them perform well under large loads, but it's not exactly rocket science. SFA, on the other hand, is still evolving in functionality. There is therefore a much greater need for design creativity to come up with long-term viable products, as vendors must work with customers to first understand then implement the functionality.
...one big difference, I believe, centers around target end users...
You're right. This is another big difference. As I said above, support automation end-users are trained to use systems and process. And the majority of support automation users are support reps. Not so in SFA. The way high-end SFA is designed today, there are many different kinds of users (e.g. sales managers, marketing people, inside sales, account managers, and yes, sometimes even salespeople). The larger user community makes it more difficult to design SFA.
At the end of your message, you answer the original question (why is support supposedly harder than sfa?) with an assertion that does not address the issue: it IS harder to get into support than into SFA. It may be harder to get into support than SFA because of the crowded market, but it is harder to create SFA apps than support apps. SFA is where support automation was a few years ago: still defining the features and functionality.
Okay, I'm done. Your turn. |
