Hi Clam:
Sorry for the late reply; out a couple of days with some minor mouth surgery (and hurt it again when my jaw dropped viewing RMDY numbers.)
re: why is support supposedly harder than sfa? One man"s opinion to follow.
There are a lot of factors that make support automation harder than SFA. I won"t go into all of them as not to bore anyone (too much). I will quickly gloss over the most obvious one, which is functionality set. Support organization business methodology is much more mature and standard than SFA, which is only now coming into vogue (thanks in part to our buddy Tom). I can remember working back in "86 at CAE Systems with some folk who started Answer (an early support automation company) while Tom was still selling seats at Oracle. This maturity in accepted support business needs has resulted in a huge set of "minimum required functionality" for support automation relative to the relatively immature SFA area. Interesting aside: at CLFY, we seriously considered initially going into SFA instead of support, but found that there was not yet the acceptance of even a market for SFA.
But one big difference, I believe, centers around target end users. I will call this the "scream factor". Generally, the targeted end user for support automation software is a support professional. I don"t know if you have ever worked this sort of position or observed someone in one, but let me tell you: it is tough. Every task is a critical task, and it is already late by the time it comes to them. Customers are generally mad, confused, ignorant, and/or generally in a bad mood by the time they get to a support person. They want an answer to their question or problem, and they want it NOW.
This high tension, high emotion environment results in a number of what I will call "psychological requirements" for support automation software. The software must perform, both from a speed point of view and a quality point of view. The customer is generally on the phone, not happy, and doesn"t respond well to observations by the support person that their support software is slow or even down. They have a tendency to associate: I have a problem with their product, AND their support person is having a problem with their support software => therefore, this is one screwed up company.
Additionally, the software must do a lot of complex things, but not be too complex to operate (quickly). The amount of turnover in a support organization is staggering. Working a day or two in such a job, you would see why (I"m sure there are those out there that can confirm). Training becomes a huge issue, as does tailoring the software to "our" way of doing business.
So, performance, quality, ease of use, and customization become HUGE requirements for support software. And guess what: these are the hardest things to do. Putting together an amount of functionality to handle the perceived functionality is relatively simple; making it work quickly, reliably, and easily in a high pressure support environment is critical (and tough). Getting it right requires large amounts of time and effort.
CLFY, VNTV, and SCOP have almost 8 years of experience in these issues. That head start is staggering; in my opinion, nearly insurmountable. On the other hand, SFA is relatively new, does not have the same level of requirements in the aforementioned areas (arguments welcome). Also, most large scale SFA solutions are based on offline database replication (which is admittedly hard) and have skirted the HUGE technical difficulties of enterprise-wide OLTP applications (an issue that I believe is at least twice as hard/time consuming than offline replication, IMHO). Also, the size of the support deals/installations is increasing; 2000, 5000, 10000 connected users. A system not designed to work in such an environment (e.g. RMDY) simply cannot scale to these workloads.
Bottom line: it IS harder to get into support than into SFA. I think VNTV is proving this right now; we will soon also be proving it with our mobilized products. SEBL will make the claim that their architecture, bravado, singularity of naming (I hear even the restrooms are named "Seibelrooms" over there) etc makes an entry into support easy, but we techies know better. But give Tom his due; he is very good at defining the game and the victory conditions; his comments last quarter about "35% share of support/SFA market" prove that (like if Ford claimed a huge share of the combined car/avocado market; how many Ford avocados have YOU bought?) Sorry, I didn"t mean to get in any Tom-bashing; he is very good for our industry (and market perception).
Sorry for running on at the keyboard.
btw: I join those who scratch their heads as to why VNTV didn"t go up following their quarterly results. I have some short term VNTV holdings, and would like to see it amount to something.
Good luck. |
