During the software acquisition process, the parties are often ready to move past the terms of the contract and implement the software to start recognizing the benefits. Even before an agreement is reached, both parties usually expect that there will be some problems in all phases from implementation, configuration, testing, and operation of the software. So, it's important that both parties determine how future software support problems will be handled.
It is not necessary to anticipate every problem and determine out how such problems should be resolved, but it is important to have a plan – and a back-up plan – to get problems resolved. Although, it may be uncomfortable to discuss potential problems at the onset of the relationship, it can be better if both parties have a meaningful conversation about the problem resolution process and set real expectations.
Many software publishers have a pre-determined matrix categorizing issues into tiers that illustrate error reporting. These matrices are typically classified by the criticality of the identified issue. Both parties should ensure that the definition of the various tiers is very clear and understandable so that when a problem arises, it can be quickly categorized and handled appropriately. Some matrices also commit to an acknowledgement time frame after a problem is reported (e.g. a Tier 4 problem will be acknowledged within 15-30 minutes). Some standard matrices stop at the acknowledgement. In these situations, it may be useful to include a commitment time frame for actually resolving the problem.
There really is no standard for a problem resolution matrix. It is important not to just find a "general" matrix and use that as a basis for the discussion. Instead, both parties should put some real thought into working through what makes sense based on the solutions and capabilities of both organizations.
As a back-up plan, the parties could choose to include a dispute resolution section in the agreement that provides an escalation chain to resolving problems when a party cannot comply with the matrix. Inserting a boilerplate arbitration clause is typically too extreme on its own. Having a list of contacts and phone numbers for each party's chain of command can be an effective way to resolve problems amicably without resorting to extreme measures that could harm a valuable relationship.
When reviewing the business's current and future technology agreements, it may prove beneficial to seek out any section in the agreement related to problem resolution and dispute resolution to determine whether the language actually addresses the needs of the business and sets clear and realistic expectations for both parties. Relying on boilerplate or otherwise insufficient language can lead to lower productivity, dissatisfaction, and higher costs for both parties.
It can be helpful to seek the advice of an attorney familiar with IT dispute resolution in software agreements to discuss ways to start resolving future problems before they begin.
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.
