Hi Shege:
Thanks for the counter. Good points.
Let me summarize the main point you were making on the Support vs SFA. You seem to be stating that the Support application market has reached the commodity stage, making entry for low-cost clones possible. What has been previously done is now so well understood that almost anyone can get into the market at a much lower entry cost (and possibly establish a lower price point per seat).
My view on this (also answers TD"s question about ERP entry into this space) is that it is easier to desire than to achieve. That is, it is easier to say that you understand a problem sufficiently to solve it as well (or better) than another. As they say, the devil is in the details (yes, I am going for a high clich‚ per sentence ratio).
Granted, the methodology applied by support organizations is well understood. However, it was well understood even when we started out; you think we came up with it? No, we went to 20 or so companies and asked "what is you support methodology" and they told us. Some even gave us specifications. We proceeded to build our applications based on this feedback, and the continued feedback of our customers and our wealth of internal expertise.
It also SEEMED to us to be a very simple problem to solve. Customers call in, you take their information, try to solve their problem, if you can"t you pass it onto someone else. Simple, right? Unfortunately, those devilish details come up.
I alluded to some of the details in my previous post. They consist of sometimes contradictory requirements. I want it to be fast, but I want to connect everyone and his brother to it. I want it centralized, but distributed. I want out of the box completeness, but it must be highly customizable. I expect it to be performance tuned, but I want to upset that tuning with my own changes. It must be 100% reliable, but I"m going to run it on our beta OS. Etc etc etc.
I don"t want to go into too many details, so maybe a couple of examples. How about starting with an obscure one. Client clock drift. Not only do you need to know the time zone difference between clients and the server, but you need to account for client clock drift. Customer support applications, timing is CRITICAL, and being off by a couple of minutes can have false alarm bells ringing (or true ones not) and CFO"s ranting ("they won"t pay their maintenance because we didn"t fix their problem in the time contracted!"). You say, why not rely on the various network administration packages to manage this? Why do you think we have this feature; to combat the effects of these "helpful" tools. We have a non-trivial amount of functionality devoted to detecting and correcting client clock drift, a seemingly unimportant detail (until the toast hits the fan because of it).
OK, maybe too obscure. How about notification? You want your notification and escalation procedures to take into consideration a wide variety of factors. Time based? Of course. Contract based? Naturally. Support hours based; you don"t want the clock running on off support hours? Ok. Customer hours based? Well, wait a minute. Notifications based on a combination of the support hours, customers contracts, holidays, time zones, allowing for different notification methods of a variety of involved employees and external parties based on their registered on hours/off hours notification paths (email on hours, pager off hours)? Whoa, whoa, whoa. All hooked up to customizable, event triggered business rules that can be customized by a manager, based on internal and customized condition factors, repeating at regular intervals on an increasing escalation path that ends at the CEO? Come on now, you don"t expect me to build that, do you? Well, we did (and I only scratched the surface of our Business Rules functionality).
Let"s talk performance. OLTP, deadlocks, indexes. Round trips, network latency, packet sizes. Disk striping, caches, locks. Optimizers: rule or cost based? Referential integrity checking, transaction recovery, multiple processors. Index strategies, runaway queries. Normalization vs denormalization. Random clustered indexes to reduce hot spots. Isolation levels, dirty reads. After all this, the customer insists on the monthly support report, which scans every table in the database, on their OLTP database in the middle of the day.
On the point of accepted support methodology versus nebulous sales methodology. Point taken. But I don"t think I agree with the resulting train of thought. I have found that as the support methodology because better understood, customers are more demanding of it. The support methodology has evolved not by survival of the fittest ideas, but by conglomeration of all ideas tried by all support managers. That is, every customer has their own twist on how support should be done, which results in needs for different functionality and/or approach. It was actually easier in the early days of support, because the expectations on functionality were so much lower. That bar is significantly higher in support today. I actually pine for those days when customers were satisfied with 1,000 features instead of 100,000. That is why SFA looks so attractive right now; it is still in that early acceptance stage where having anything is better than nothing (and most customers are experiencing their first SFA system. Oh, the naivity!)
This answer also applied to TD"s previous post. Of course, it looks easy from PSFT"s point of view to get into VNTV"s space. But what self-respecting engineer won"t tell you that? He/she would have to turn in their pocket protector if they didn"t say "that is easy". It"s part of our credo; I can do anything better than you (la la la). If they could, they would; there is certainly money to be made. Then why don"t they? Because they have (or should have) more important things to do in their own space. Priorities are always on meeting the current quarter, getting the next big deal, etc. If you mess around too much in areas outside of your domain (and competition), you get your ears slapped back (you listening, Larry?)
Having said that, I think it is significantly easier for a PSFT to get into this space than, say, a SEBL or ORCL. SEBL"s too small, ORCL proved they couldn"t do it. PSFT might be able to, but they would need a significant investment and perfect execution. Why not just partner with VNTV (better yet, us!)?
Front office has taken off. If you aren"t in the race now, it is too late. You would need to buy your way in now. Either way, the race is critical. And there"s money to be made by aggressively wary investors all along the way.
Jeez, I hope I don"t get charged by the word... |
