Support and Maintenance Portal

To content | To menu | To search

Tag - Support system

Entries feed - Comments feed

Thursday 18 August 2011

Hurry! Hurry! Hurry! when a business stand still is logged

Customers really depend on their software to earn their living. When they for example can not send out invoices, they have a major problem. When they can not send invoices they will not receive money from their customers. When they do not receive money they can not pay their own bills. Such a situation could end in bankruptcy.

Do not think such a scenario is exaggerated. It is a nightmare for your customer. He will act accordingly. When you do not respond properly he will strike back furiously. You will go down under with him.

Continue reading...

Register spend hours on reported defects

When you want to have more insight in the bug solving process you should register hours spend directly on reported defects

Such hour registration gives you insight the usage of time for:

  • the several products and product lines
  • valid and non valid defects
  • the several maintenance engineers (group, department, country, region)
  • the several priorities (business standstills, major problems and minor problems)

Take over from Development

When Maintenance is not part of Development the transfer of a released product need to be arranged well.

The following need to be arranged and is the responsibility of Development:
  • Knowledge Transfer to Maintenance Engineers on a Technical Level
  • Knowledge Transfer to Support Analysts and Maintenance Engineers on a Functional Level
  • Transfer of the product from a Development Server to a Support and Maintenance Server
  • Activation of an Operational System to start up Support and Maintenance straight away
  • Transfer of the product documentation

When a product transfer is not done properly Support and Maintenance will not be able to provide the correct service levels to the customers. Money is lost. Development is responsible for this loss when one of the above points is not arranged well.

Continue reading...

Tuesday 16 August 2011

Customers only want their own functional changes

A customer only wants you to build his requested functional fchanges and not those of other customers. A functional change, especially an unexpected one, could severely upset the customer system or his systematics.

You have to decide how you will coop with such requests. Keep in mind that there will always be a big grey area. An area under the influences of threats of contracts breaches or lawsuits.

When to consider and when not

Continue reading...

Trace-ability of changes

All changes done in the source need to be marked. Marking makes it possible to trace changes and to collect all parts of a solution and provide it to the customer.

Mark with the solution number 

A solution could cover several sources. When a solution turns out to be a bad fix all adjustments of the solution need to be found. To be able to do that, all changed need to be marked with the solution number.

The solution number makes it possible to discuss the error with the Customer and the Support Analyst. You are sure you are all talking about the same problem and thus about same source(s).

Solutions that turned out to be Bad fixes must get an indication so Customers are aware of it. When a new solution fixes the bad fix, a reference to the new solution must be given on the old solution so customer can download it. All this must be visible for Customers when they look at solutions in their self-service solution database.

Monday 18 July 2011

Report Hours on Reported Support Issues

When you want to have more insight in the Support process you should register hours spend directly on Reported Support Issues.

Such hour registration gives you insight the usage of time for:

  • the several products and product lines
  • the several support analysts (group, department, country, region)
  • the several support issues priorities (business standstills, major problems and minor problems)

What are your Basic Support goals?

When you set goals for your Support organization your have the opportunity to state how you want to bring people, infrastructure and technology into action.

Ask yourself the following questions when you are defining the basic goals for Support:
  • Which product(s) do you want to support?

Continue reading...

Access to knowledge

For a Support organization access to knowledge is very important. The goal is to provide quickly good answers (and solutions). To be able to do that you require well trained personnel. When your software package is large it will be quite difficult to have every Support Analyst well trained on all areas. In time experienced Support Analyst will leave your company and other (junior) Support Analysts will join. You have to keep on training.

Continue reading...

Develop the skills of your Support Team

Support and Maintenance contracts could bring in a lot of money. Money you can spend on new development. To keep customers paying for Support and Maintenance contracts you have to offer them a good return of investment. Services and actions from your side influence the customer's return of investment for a very great deal.

Services and Actions like:
  • Direct response on business standstills
  • Error analysis and solving on the customer system
  • Bug Fixes
  • Advices and Workarounds
  • Enhancement requests and Customizations
  • Guidance during installation, upgrade or migrations
  • Documentation

To be able to provide all these services and actions it requires a reliable and knowledgeable Support team. A team that knows how to approach a customer, minimize his anxieties and problems. Training, policies and procedures have to be a daily concern to management to improve further and to keep the customer's return of investigation high.

Continue reading...

Sunday 17 July 2011

Measure Support Performance

Performance can only be measured when performance related data is available in the Support System.

Master Data

When you like to measure the performance for Individual Support Analysts, Teams, Departments, etc, you need to have this data as master data available in your Support System. So your organization structure needs to be somewhere in the Support System. Same counts when you would like to measure performance for Customers and Product (versions), service or feature packs, packages, modules, etc, as well.

Performance Data

Performance data is data that tells you how well you handled or are handling a reported Support Issue. The following aspects are important for internal and external usage:

Continue reading...

Rotate Reported Support Issue directly to the right Support Analyst

The customer should be able to log their own Support Issue. You should promote that they do as much as possible themselves because this speeds up the process on your side. Customers should get the option to attach documents to support the clarification of their reported problem. Customers should also get the opportunity to state the importance of the problem to you via a priority setting.

Master Data

Of the customer master, contract, login and used product data need to be captured. This data has to be up to date. Every year you should ask your customer to check his data. Support Analyst must go blind on this data to be able to do their job properly. An error in this data could lead to a disturbance and possible to increased waiting time for the customer.

Rotation

Continue reading...

Friday 8 July 2011

Many possible closures require skilled Support Analysts

Reported Support Issues end in different ways. Here is an overview of the several options:

  • Answer to a question
  • Explanation about the functionality
  • Data correction
  • Workaround
  • Reference to the Customization Department
  • Enhancement request for future usage
  • Software fix

What ever the end may be, a customer has to agree, else the ping-pong between you and the customer will go from bad to worse. A clear Support and Maintenance policy as well as a well considered Support and Maintenance contracts will help you. But what the most will help is to act consistently. The role of the Support Analyst is the most important role when the company wants to increase net income from the Support and Maintenance contracts.

Train your Support analysts well. Not only on the product but mentally as well. They have to face difficult and demanding customers. The more the Support Analyst can stop from going to Maintenance the more money can be earned for the company. The more money the company can invest in creating (new) products your customers want, the better your company can compete with the competition.

Thursday 7 July 2011

Try to speed up but do as less as possible

Support Issues could come in via several channels like phone, fax, email or internet (Support System?). Phone, fax and email are unstructured and require action from your site... to put them in a format your organization can digest them. Having the customer register a support issue that contains all necessary data is a lot cheaper than doing it yourself. A Support System via the internet could do the trick for you. Such a system should have the following characteristics:

  • Customer master data (CRM?) 
    • Customer details 
    • Contract Details 
    • Active applications or versions 
    • Contact information 
    • Dial in information
  • Product Master data 
    • Application / Version Information 
    • Package/Module/Session information 
    • Toolset information 
    • Database information
  • Support Issue related data 
    • Customer Master data 
    • Product Master data 
    • Problem Description 
    • Reproduction Material (for example an attachment with screen dumps) 
    • Impact Description 
    • Expectation Description

A Support System should provide you as well as the customer a follow up mechanism. The follow up mechanism should manage the expectations of your customer. By providing data about progress for example by showing the current status (new, on hand or closed for example) the customer knows a bit more about what to expect from you.

The Support System should provide you with the option to move Support Issues to and from different people. After first analysis the support issue should move to a more knowledgeable analyst on the matter, sometimes it needs to move to a different group within your organization.

To get a support issue on the right spot the Product Master data, set by the Customer on the Support Issue, should be the basis to rotate issues to the different groups or individuals within your organization. Of course the Customer could be wrong about the product/package/module/session and the first contact person within your organization has to reroute. The quicker this process can be executed, the quicker you will be able to provide a solution, the more at ease (not satisfied) your customer will be