ReRe: support's view on customers

The internet could be a very small place. One of my clued-up customers is aparently also my subscriber (and vice-versa).

He was wondering why questions from 'intelligent customers' do not go straight to Backline (tier-3) support.

There are several reasons.

First one is that Backline (BL) and Frontline (FL) support (as BEA names tier-3 and tier-1 correspondingly) actually have different strength.
Frontline support is very good on collecting initial information, checking documentation and internal support databases. They may seem a bit information greedy, but often missing a configuration file at the start may lose a lot of time later. Essentially, FL DREs are very good at connecting the 'known' dots.

Backline support engineers on the other hand are much better at the hard problems and at problems with hidden variables. We are also the ones familiar with non-BEA technologies and other developer land tricks.

When I (a BL support) had to do a Frontline engineer's job, I sometimes find out that I miss basic information nugget that would have been collected by a FL support and matched against a known issue. I would get to the same information via replication or source code search which is more general technique, but may takes longer.

In most of the cases, leaving the case to FL DREs until they are ready to escalate is really the best way. Especially, since FL will often bring in a BL engineer behind the scenes to just get a read of a case and confirm the direction taken. That way, the customer still deals with one person, but gets the expertise of two (or sometimes even three) engineers.

The second reason is to do with a field of expertise. A JMS specialist may not know much about certificate signing; an EJB guru is fairly unused to the network issues cases by firewall for remote clients. Support engineers (FL and BL) are trained to be jacks of all trades and even FL engineer is more than enough support presence for a customer working out of his/her depth.

The final reason is simply financial. Higher priced support offerings allow a faster access to senior DREs (FL or BL). Some offerings even have dedicated DREs (at least in their own timezone). Also, the more money goes into the support. the more company is willing to hire additional people to do it.

Finally, just to comment on the support question Dim was writing about, I looked it up. If I found the correct case (from mid 2003), it was actually resolved by me via replication and turned out to be the correct - if not obvious - behaviour with the given configuration.
Customer was frustrated because it took a while to figure the problem out. Why did it take so long? Well, it turned out that I was missing customer's configuration file (config.xml). In absence of it, I followed written down configuration instructions, which turned out to be incorrect on one tiny, but crucial point of JMS file store configuration. A frontline support engineer would have ensured that the config.xml was collected as a compulsory first step.

In conclusion, I am sure that there are good and bad cases. BEA's near future goal is to actually concentrate on making the support better, faster and more proactive. In fact, I have some visibility and influence into the process. If you are a BEA customer and have a real suggestion on how BEA support could be better, put it in the comments.

BlogicBlogger Over and Out