Support Issue Workflow

by James

Where Dydra appears, in public, as a strictly remote service, the question occurs —

“If one cannot walk down the hall and knock on a door – or pound on a table, how does one get issues resolved in a timely manner?”

Any claims, that our response completion statistics are well over three nines notwithstanding, a better answer describes how we resolve those issues which do appear in a manner which ensures that 24/7 customer operations remain in service.

One aspect is a transparent process to record and track issues. The second is a well-defined response and resolution process.

Issue tracking is straight-forward. For public issues – that is, whatever happens on the site, we maintain an open issue repository on github. The public site is rather stable — issues appear rarely. For dedicated installations, we maintian confidential ticket, with access distinguised by installation.

The response process is a separate question. For dedicated installations we provide several response levels

  • critical : issues which prevent operation
  • major : issues without a work-around, but also without service interruption
  • minor : issues with a work-around
  • other : feature requests and enhancements

Where each has well-defined contacts and roles, an agreed response time and a goal for resolution, customers know what they can expect and how to contribute.

The most concise explanation is a compact graph of the response workflow.


blog comments powered by Disqus