North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: outages, quality monitoring, trouble tickets, etc

  • From: Alan Hannan
  • Date: Sat Nov 25 15:34:29 1995 
.........  Sean Donelan is rumored to have said:

] Customer service should be of interest to operations folks, at least 
] to the extent the problems are getting reported to the right people to fix.

  It certainly is here.

] I doubt I can change anyone's mind that providing explanations to
] customers and non-customers when the network has problems is good for
] business.  

  I agree with you that it is important.

] In the future I will simply recommend to customers to buy
] services from NSPs which do provide explanations when their networks
] fail.  Since I haven't found a perfect network yet, I suspect it
] includes everyone on this list.

alan>  rope to the other guy.  It just doesn't work, there's nothing in
alan>  the system to encourage it.

  What I mean by saying this is NOT that I don't think a per-NSP
  trouble reporting mechanism is a good idea.  What I'm saying is
  that within our Internet arrangement today, I don't see that it's
  terribly capitalistically useful for NSP-A to adverise internal
  problems to NSP-B.  There is no doubt in my mind that it IS
  terribly useful for NSP-A to advertise internal problems to
  NSP-A's customers, as well as to NSP-B if they inquire on behalf
  of NSP-B's customers wrt an outage internal to NSP-A.  You're
  right the migration of customers is a good metric, but it's hard
  to quantify that migration wrt trouble reporting to management.

  A friend at MFS brings up a good point, that being that the COREN
  agreement stipulated for a trouble reporting list.

  Perhaps we could work to develop a scalable model of such for
  world wide Internet use, or adapt that to this.

  Any other suggestions? 

] If you aren't providing the level of service I need, I'll go to someone who
] can.  If XYZ's NOC gives me better service than ABC's NOC, I'll 
] recommend XYZ to my customers.

  Adam Smith's rules _will_ follow us into the Internet.  Agreed.

] >  Sprint.  I certainly see no reason why I should do this work for
] >  you.  
] 
] Because it is in their self-interest?  You are correct I can't make
] anyone run their network how I would like it run, not even MIDNET (GI).
] 
] But I can point out long-term problems and code of silence is costing such
] providers money, and has already cost them customers.  

  It's not a code of silence.  That's my point, that being that
  historically when we are asked about problems we give darn good
  answers.  That we don't directly advertise problem attention or
  resolution is not correlative to our response to requests.

  Should we provide darned good answers?  - YES
  Should we provide automated Darned Good Answers to our customers? 
						     - YES, it would be nice
						     but not a NEED,
						     rather a nifty
						     service (IMHO)

  Should we provide automated Darned Good Answers to other NSPs? 
						     - YES, it would be nice
						     but not a NEED,
						     rather a nifty
						     service and
						     lower priority
						     than #2.

] I might call BARRNET because the University of California-Davis has
] reported problems reaching DRA to DRA's help desk, and the problem hasn't
] been resolved.  No, BARNET doesn't *have* to talk to me.  And I will
] report the same back to the customer.  However, I suspect it is in
] BARRNET's self-interest to work with me in resolving the problem
] to ensure UC-Davis has end-to-end reliability.

  I agree it is too.  However, when I hear people complaining about bad
  NOCs, I think it is important to point out that there is no
  mechanism in place to hold those other NSPs accountable as the
  person complaining is rarely the customer of the NSP.  Yes it's in
  our long term interest, but that doesn't mean there's something in
  place to encourage it other than honest intention.

] I track network reliability by dollars (not packet loss, not latency).
] I measure network providers, good and bad, by how many of our customers
] have used their own dollars to buy private lines to St. Louis because
] they couldn't get the reliability they needed from the network provider.

  Ouch.

] As I said before:  Ideally I want a reliable network.  If you can't
] provide a perfectly reliability network I want an explanation when I
] can't get through.  And I want the problem fixed.  The better the
] explanation, the longer I'm willing to give you to fix the problem.  If
] I get no explanation, I expect the problem to already be fixed.

  This is a good point, and I have been more convinced that it is
  important.

  Because of this discussion I am going to work to develop an
  automated WWW status page.

] The current situation is the customer gets neither the explanation nor 
] action solving the problem.  

  I appreciate that NSP response is not always ideal.  However, I
  would encourage all people who get a less than exceptional
  response from a NOC technician to escalate the question so as to
  improve the NOC quality.  No, this isn't something you should have
  to do, and it's not something that makes anyone terribly proud but
  it does tend to improve the service by natural tech selection.

] Since the technicians seem to be having a very difficult time fixing
] the network, I thought upper management could meet my other goal.  Give
] the customer an explanation.  

  This is done when they ask, and due to your and others concern, I
  am going to work to develop an automated web page showing down
  time problems.

] The Internet is a global cooperative network.  If people don't cooperate,
] the global nature of the network fails.  

  Agreed.

] Can't NSPs provide their customers an explanation at least as well as
] the US Post Office?

  Yes, it's possible, and due to this discussion, I am going to work
  to build one as nice as FedEx's....  Anyone want to volunteer
  joint development? :)

  -alan