Support Issue Workflow
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 dydra.com 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