% fortune -ae paul murphy

Minimizing after sales disasters

As discussed earlier this week, the current recession combines well with recent technical change to open new opportunities for Unix sales into the x86 and mainframe worlds.

That sounds good, but remember the last great Unix sales boom? All those big Sun and HP boxes moving into Web enterprises and mainframe shops during the mid to late 90s? A majority were bought by people whose belief that what they knew about running Windows or OS/390 applied to Unix eventually put thousands of these machines on the used market, led to a revival in mainframe sales based on blaming Sun for their failures, and left the entire Unix market depressed well into 2004/5.

That's inevitable this time too: as economic necessity forces people who know how to run Wintel data centers to use Unix, they'll apply what they know - and, by doing that, ensure that their employers never get the benefits available from the change.

From a sales perspective, therefore, the way to protect your company and yourself is to plan for the longer term - get the boxes in there, yes; but then put a lot of serious effort into providing the support needed for the customer's employer to get the benefits you've sold him.

How? Well, there usually isn't anything you can do when a customer gaurantees project failure by blandly refusing to acknowledge that Unix is neither Windows nor zOS - but there are some things you can try to minimize the severity of, and the fallout from, that failure.

For example:

1. (gently) discourage grandiose schemes. If your customer plans major infrastructure change, don't just take the order. Counsel a go slow strategy, waste your own time and that of whatever customer engineer time you command to push cultural change along with HW/SW change in the customer's IT group.

   Remember: the customer will deeply resent any obvious interference, but letting some guy who thinks DA an identity management system assign a bunch of MCSEs with a few hours of Solaris "training" to run an enterprise Unix transition - or even a cell based Linux compute farm - is a guaranteed way of ensuring both his short term failure, and your own long term loss of that customer.

2. for larger customer opportunities counsel pilot projects, put maximal engineering support behind those projects, and instruct your on-site people to spend most of their time smoozing, not working: i.e. focus on getting customer assigned staff thinking Unix, not on doing Unix for them.

   The bottom line is simple: it's rare that a customer can't go another six months or longer on existing gear, so using a pilot project as a vector to introduce some new ideas buys you the time to get them thinking Unix - and that vastly improves both their chances of success and your chances of keeping them as happy, long term, low maintenance, customers.

3. for smaller customers, or big customers doing small things, sell culture more than boxes. Get their staff involved with your engineers, make that success relationship personal, and get them started toward thinking in terms of Unix, not Windows or zOS, management ideas.

None of this stuff is easy: when your customer wants to be assured that a T5440 can be configured as 256 virtual machines and run at better than 96.5% utilization, you know he's beyond the reach of reason - but what you should also know is that the people he assigns to work with your engineer on the pilot might be reachable, and that the senior executives he ultimately reports to certainly are. The right approach, therefore, is to take his money - and then work on the people above and below him to reduce, at least a little bit, the likelihood that this customer's company will blame your technology for the disaster he's going to create.