On paper this all sounds idyllic, but in reality it never works out that way
I am afraid. I think it is generally expected that the only time a vendor
touts response time will be during the sale... after that, there seems to be
some disconnect.... until the yearly license renewal comes up that is...
You get what you pay for in this business. If you can afford 24x7 onsite
support, certainly you are going to get better service than if you rely on
multi layered responses over the phone.
Making a call to say I am on it may be a sign of courtesy, but it does not
get the client back on line.
I look very hard at the service I get during the year, and do not hesitate
to change resellers if there is a major problem. But not before voicing my
concerns and giving them an opportunity to resolve the issue. And as far as
pricing goes, I think there will be some that will try to get by on the
cheap...but if I find a vender I am confident in and have received good
support from, I will gladly pay him a little more for that service. In the
long run, I have found that cheap in not always cost effective.
> -----Original Message-----
> From: Paul D. Robertson [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, January 23, 2001 9:38 PM
> To: opie san
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Response and resolution times
>
> On Wed, 24 Jan 2001, opie san wrote:
>
> > >1. What is the reasonable minimum for response time on a support
> contract?
> > >
> > A customer should receive a response within the first 4 hours or so at
> the
> > very latest. Customer's with higher grade support should expect a
> quicker
> > response time if they don't already have an assigned engineer that they
> call
> > directly instead of having to work through the phone tree or front line
> > engineers. Even if this is nothing more than a "Hello, I'll be working
> your
> > case today" message with contact info, this at least gives the customer
> a
> > name and number/email address to ping or send updated info to while the
> > initial research is being done.
>
> I think the idea would be that this is the minimum necessary 24x7x365
> support contract offered by a vendor of firewalls targeted at a Fortune
> 500ish market. It wouldn't address costs, other support options or things
> like that, so your "Hello, I'll be working your case today" scenerio is
> exactly what I'd expect to be offered in response to such a requirement
> at a minimum. I'm hoping that by making this sort of thing a visible
> potential requirement, some market differentiators will hop in with both
> feet and we'll see more significant support offerings enumerated up front.
> It's certainly one of the bigger headaches in firewalling that I've dealt
> with in the last few years.
>
> > >2. What are normal parameters for required escalation to a higher
> level of
> > >support?
> > >
> > Depending on the structure of the support department, the first support
> > engineer to work the case will most likey be a Jr. level person that can
>
> > answer the easy questions (read FAQ's) with well known answers. If they
>
> > can't resolve the issue within the first phone call or first day (once
> again
> > depending on the support organization), then it should be escalated to
> the
> > next level. This second level group may take more time to research the
> > problem and collect information from the customer. It should be
> apparent
> > within a day or two whether or not the problem is within their ability
> to
> > resolve. If not then it should be escalated again to the next level up
> > (provided that the support org. has more than 2 levels). Usually only
> the
> > really quirky problems that hide in the back corner of your attic make
> it
> > this far. Stuff only the veterans may have seen or been informed of by
> the
> > engineering department, etc.
>
> Please keep in mind that if these questions morph into criteria, they'll
> have to apply to lots of different vendors (and whatever structures they
> have in place.) Do you think that requiring some sort of 48 or 72 hour
> "close/escalate/update with status" criteria is appropriate? Probably
> that'd have to be "business days at the target's support location" if they
> had a single location.
>
> It'd help if you provided some info on your perspective (enterprise admin,
> vendor support...)-- it's not necessary, but it certainly would provide
> more insight into where you're coming from, which in turn helps us in
> thinking about this. [My own perspective is mostly as a former security
> officer/administrator at a large corporation, with some generic security
> geek
> stuff thrown in. That's been the basis of my participation with the
> firewall program people at the Labs.]
>
> > >3. Is it reasonable to have an absolute contractual deadline for final
>
> > >issue
> > >resolution, and if so, what is a reasonable amount of time for this?
> > >
> > I don't think its reasonable to say that any problem will be resolved by
> a
> > certain time. I've seen plenty of issues that lasted for months due to
> > things like needing an upgrade that the vendor has not released yet or
> the
> > problem needs to be captured in action and can't be manually triggered.
> It
> > is reasonable to expect that a resolution will be provided in a timely
> > manner (to eliminate the tech support folks that drag ass on getting
> back to
> > customers or spend too much time playing Quake instead of researching
> the
> > problem) but not an absolute deadline written into the contract.
>
> "Resolution" and "Within a timeley" manner seems difficult to address
> without arbitration, but I think your answer to #2 is helpful in how we
> think about this, and certainly might fit well in the scheme of things.
>
> >
> > Hope this helps.
> >
>
> Definitely. Thanks for the quick feedback!
>
> Paul
> --------------------------------------------------------------------------
> ---
> Paul D. Robertson "My statements in this message are personal
> opinions
> [EMAIL PROTECTED] which may have no basis whatsoever in fact."
>
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
