Are the days of the showpiece NOC office display gone forever?

Wed Dec 30 23:04:02 UTC 2020

On Tue, Dec 22, 2020 at 10:41:43PM -0700, Wayne Bouchard wrote:
> And if the last 15 years has shown us anything, it is that when you
> can't get past the auto-attendant and talk to a real human, and if
> that person can't talk to you like a person instead of reading scripts
> at you, your stress levels go way up as does your desire to break
> things. Automation in customer service (or excessive emphasis on
> procedures) is a really nice way of taking a five minute problem and
> turning it into an hour long ordeal.

There are some easy methods for service/support organizations to decrease
the pain that this inflicts on people reporting problems.

For example, one thing that I've taught people to do is to make liberal
use of procmail in order to sort incoming traffic to role accounts.
It requires diligence, but that diligence is repaid many times over by
how it expedites dealing with problems.  A simple example of this is
that when a problem report is received at the RFC 2142 security@ role
address, and it's clueful, well-written, and important, a procmail rule
gets created for the sending address so that all future messages from
that address are prioritized...because it obviously came from someone who
knows what the heck they're doing and did us a favor by telling us that
we have a problem.  Chances are that any future messages from them will
be similarly helpful and that if we respond to those quickly we may be
able to forestall a lot more messages that aren't going to be as clueful.

The opposite thing is done with clueless/misdirected/etc. reports:
they're not discarded, but they go into the low-priority queue.

Everything else goes somewhere in the middle.

Repeated hundreds or thousands of times over many years, this builds a
ruleset that pre-sorts messages rather well.  It's not perfect, it's not
foolproof, but it helps us *and* it helps lower the frustration level of
people sending clueful messages, because it better positions us to read,
act on, and respond to those.  Those people are catching our mistakes,
the least we can do is try to pay attention.

(Hint: a useful way to begin building such a ruleset is to grab all the
addresses from NANOG, dnsops, outages, etc. and pre-load the ruleset
with them...because traffic received at role accounts from participants
in these mailing lists is probably useful.)

---rsk