| Dave,
We have a problem here which will keep biting our bums from
time-to-time. The call you refer to (BTW thanks for you help), says
SUSL for contract coverage. If you look at the call for contract
coverage it shows S/W as SUSL and all the H/W I bothered to look at as
DSS. When I called the customer today with your recommendations, he was
slightly miffed when I said the magic word 'SUSL'. He said you use to
say that before but I haven't heard that for sometime. On this system
everthing is on DSS contract. When I mentioned that it was possible a
problem with DTDRIVER he said that's great you can close the call.
Ouch.
Norman
|
| yes it can be a bit delicate discussing contracts with customers.
Another options would be to pass the call to the contract validation group.
(can't remember the hunt no, but Bev Dore is the supervisor and they sit
upstairs between ccd and response.)
Now they don't do Sw validation yet, but since we are a hw/sw group can
probably get them to check the hw part of the contract. Also they probably
will start doing SW validations later in an attempt to raise come cash!
Nb one reason for this note is to try to get our working practices in line
with the vms group. We want to eliminate any reasons why customers log calls
with one group because they get a different service. Any other anomalies we
should be dealing with?
dg.
|
| one more thing to explain the susl/dss thing. The support contract is sold as
dss/bss or sats. This is sold against hardware, but includes automatic software
support for the operating system and decnet (and any licenced additional
software ).
susl is the licence update service. if a customer has this then it means they
have paid for the licence to use the software (doesn't necessarily mean they
have support, they get support if they take out a support contract on the
hardware as long as the software is licenced).
So a customer needs both to be supported strictly speaking. However due to the
way calls are logged (against whatever the customer quotes, they look for a
match on the contract record and select that) we only ever see one thing.
There is a possibility this may change, me and jon morris come up with some
proposals ages ago, but this may well take a while to happen.
|
|
The way that the response groups are being forced to log calls,
i.e without any validation/DPL checks is leaving us wide open
to throwing away possible income, and providing a free service
to customers.
Sometimes it is obvious, that the call is logged against a system
that is different, to the one that has the problem. eg log # 49172.
On other occasions, it is not until we talk to the customer, that
we find we are being asked to diagnose something different.
CLUK numbers only confuse the issue even more, as we have no way of
knowing what in the cluster, is really on contract. It can be
embarassing to ask customer to prove a contract, and that should
not be the job of technical specialists, anyway.
I think the main problem, is that the hit/pain/cost is only on the
CSC and not on the branch or contract admin etc. To my knowledge,
the contracts database has not been accurate for 20+ years, how
much longer will this situation be allowed to go on ???
Should we send any suspect call for vaildation ??
Should we ask for a PO prior to diagnosis, on "suspect calls" on the
basis that we may need to charge ??
Should we inform the customer up-front, that if we find they are not
covered, then we reserve the right to charge ?? Ought to have a PO
first, just in case !!!
I agree that we should be consistent with other groups in what we will
diagnose. i.e if VMS say "Anything before Version x.x is chargeable"
then we should play by the same rules. As Dave says, we cannot have
customers logging calls with a specific group, to get service that they
may not be entitled to.
Also agree that where third party software is involved, we should get
a PO first, in case we need to charge.
Brian.
|
| I feel that one area where we give away service is when calls are logged by
response against a valid system with a contract, and then discover that the
call is not for that system at all. Quite often it is seen within the
text of the Problem Description which states a different system to the one it
logged against, or its discovered upon talking to the customer.
It is too easy to just carry on regardless and just give away free service.
An example I dealt with is log 49172. Logged against 6420 with a contract but
stating the problem was with a m3100 which proved to have no contract.
My feeling is that these calls should be sent immediately for validation BEFORE
we do any work on them, either by our resource controller as was done by Debbie
or by sending them to the SPA group, but we need to be consistant in which we do.
Or should the problem be fixed at Response by logging calls correctly in the
first place. My "perception" is that Response are being goaled more on quantity
rather than quality, and validation is no longer part of their role.
Mike.
|