Support Request Severity

[bradrydzewski]

Support Request Severity
Critical Support Requests are Support Requests that report that:

• Customer cannot install the Software by following the directions in its documentation.
• The Software crashes or becomes unresponsive.
• Software errors prevent Customer from using the Software.
• The Software contains security vulnerabilities.

I prefer a severity definition more along the lines of this -

Production application down or major malfunction affecting business and high number of staff

The concern I have with the current wording is that Software errors prevent Customer from using the Software could encompass the majority of reported issues. The vast majority of issues I receive are false positive (e.g. the build failed, it must be Drone's fault). Each time this happens, it is blocking the developer, but does not warrant critical escalation. For this reason, I like specifying that it must be impacting a high number of staff members.

I have also seen wording like this:

When a process cannot complete, there is no workaround and the solution is business critical.

I think in this case the vague definition of business critical might work in the favor of the Seller, or would at least give a customer pause before invoking a critical support request.

[kemitchell]

@bradrydzewski I agree that the current Critical Support Request definition on master needs improving. I'm not yet sure how to go about that, though.

Definitions like the ones you mention are definitely common. But they often fail to make any sense in for particular software.

To be more constructive, here are the major constraints I have in mind:

Objectivity: The trouble with definitions based on subjective elements from the customer's point of view, like whether something is "mission critical", is that every problem is critical to somebody.

We see that crop up especially when terms give customers the power to classify support requests. Lo and behold, junior in-house developers rushing to meet deadlines don't read documentation, run into well defined, intentional behavior, and report "critical" support requests in the midnight hour. It's certainly critical to them.

Meanwhile, to the wrong kind of top-level manager at the other extreme, every business is critical. Because it's business.

Generality: This aims to be a fundamentally generic form, applicable to nearly every kind of software. It can't achieve perfect fit for all kinds of software. Folks are still going to have to read through and make sure it works for them. But we should do what we can.

#3 takes one line item out of the definition of Critical Support Request that clearly don't belong. Can we refine the remaining items to make the whole workable, or do we need to bite the bullet and accept a single definition focused on business impact?

[bradrydzewski]

I definitely understand the challenge here :)

I generally like the idea of impacting multiple people as critical, because while not perfect, it is usually an accurate measure of when something really is critical (application outage, severe bug, etc).

I should point out that my software is very complex in nature and has very high support costs (every time a unit test fails, people blame the CI system. It works on my laptop but not in CI. etc). So I am perhaps more sensitive to the definition than most would be.

Perhaps we could instead solve this problem with some command line flags that let me delegate the definition to a separate file or exhibit. For example:

Maintenance and Support Provided.
During the term of this Agreement, Developer will provide the “Maintenance and Support” services and comply with the “Service Levels” set forth in the Maintenance and Support Policy attached as Exhibit A [located at [Insert URL]].

[bradrydzewski]

I would probably retract my previous comment. I think you have written the contract in a manner that makes it easy to customize and include slightly different language. I should be able to manually edit like this:

-Critical Support Requests are Support Requests that report that:
+Critical Support Requests are Support Requests that report that: a process cannot complete, there is no workaround and the solution is business critical.

or this:

-Critical Support Requests are Support Requests that report that:
+Critical Support Requests are Support Requests that report that: the _Software_ crashes or becomes unresponsive, or there is a major malfunction affecting the business and a high number of staff

Since this section can be easily customized when needed without having to update a bunch of references throughout the document, I view this section as being successfully written.

[kemitchell]

@bradrydzewski See #11.