Thursday 18 August 2011
By Jan Verlaan on Thursday 18 August 2011, 11:29 - Polictical Escalations
When a customer is not getting the attention it demands it will find it ways
to get it. He could call the manager of the Support Center if he knows his name
(or number). But often your CEO is called directly. Especially large
companies operate this way. Your CEO is not waiting for such frustrating calls.
He will delegate immediately.
Having a group installed handling Customer Escalations provides the option
to quickly redirect Escalating Customers. The Escalation manager is the contact
person for the customer. He should organize calls with the customer to inform
the customer about progress. When customers are at the top of their escalation
daily calls are no exception. When the escalation goes to an end a call on a
weekly basis is often enough.
When the escalation has ended the customer need to return to normal Support
and Maintenance mode. The customer and the rest of your organization should be
informed about it. Internally an escalation list could help you providing this
information but a personal call or email will do a much better job.
no trackback
By Jan Verlaan on Thursday 18 August 2011, 11:24 - Polictical Escalations
Escalations, especially Political Escalations, need to be know in all layers
of the organization. When several customers have been escalated by Management
the priority between customers need to be defined. This priority has to be
used to determine which reported support issue need to be picked up first. The
set priorities can be used by all Management layers as well as by all Support
Analysts and Maintenance Engineers to keep focus on what is mostly important
for the company.
Have a list available, on the intranet for example, that can be reached easily.
Make sure the list is always up to date. Provide next to priority an overview
of the issues that need to be solved at the customer site. The better the
information that is provided, the easier it becomes for the organization to
respond quickly to the reported Support Issues of these customers.
On the escalation list the following data is required to handle escalations
better:
- Customer name
- Escalation date (How old is the escalation?)
- Escalation manager (Who is the contact person for the customer?)
- Priority (Top, High, Medium, Low)
- Situation at customer site (Short Description)
- Overview of issues to be solved (Headlines only)
- Executed Actions (Headlines only)
- Status of Escalation (New, On Hand, Closed)
- Last updated date
Such a list should be updated at least on a weekly basis. Escalation
Managers are responsible for the content.
no trackback
By Jan Verlaan on Thursday 18 August 2011, 11:16 - Polictical Escalations
Some customers are very demanding. They sometimes threaten to stop
implementing the product or stop paying the Support and Maintenance contract.
Although, from your Support and Maintenance Policy, their reported Support
Issues should be closed, you could loose these customers.
A large or well-known company using your product is good advertisement to
convince other candidates to buy your product. Doing a bit extra keeps the
customer happy and will probably spread the news. More income could come out if
it. What are you going to do?
A customer not paying his Support and Maintenance contract (sometimes for
good reasons) is very bad advertisement. This customer could ruin your
reputation. What are you going to do?
Continue reading...
no trackback
By Jan Verlaan on Thursday 18 August 2011, 11:13 - Business Stand Stills
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...
no trackback
By Jan Verlaan on Thursday 18 August 2011, 10:59 - Maintenance Policies
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)
no trackback
By Jan Verlaan on Thursday 18 August 2011, 10:56 - Maintenance Policies
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...
no trackback
By Jan Verlaan on Thursday 18 August 2011, 10:46 - Maintenance Policies
When a solution is not complete your customer will return. Again a
Support Analyst has to look at it and investigate what is wrong. The Support
Analyst has to create a defect explaining short and concise what the
problem is. All very unnecessary and costly. Money that could easily have been
saved when you paid a bit more attention.
Continue reading...
no trackback
Tuesday 16 August 2011
By Jan Verlaan on Tuesday 16 August 2011, 13:12 - Maintenance Policies
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...
no trackback
By Esther Verlaan on Tuesday 16 August 2011, 13:09 - Maintenance Policies
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.
no trackback
By Esther Verlaan on Tuesday 16 August 2011, 13:06 - Maintenance Policies
Sources programmed clear, concise and readable require less maintenance time
than those who are complex, large, and non-readable.
You require directives on the way sources are written. This starts all ready in
Development. Make sure Development provides proper code that is easy to
maintain. Depending on the language used directives should be given. The re-use
of functionality (functions, dll's, etc) is one of the most important points
next to a readable source.
no trackback
By Jan Verlaan on Tuesday 16 August 2011, 12:10 - Maintenance Policies
When you receive support issues that turn out to be defects you could decide
to only solve it at the customer site. It is cheap for the short term. What
happens when the customer upgrades to a newer version or service pack depends
on your amount of pro-active maintenance!
When there is no pro-active maintenance in place the customer will run in to
the same error again after upgrade. That will definitely harm your
customer's level of satisfaction.
Pro-active maintenance is wise when you have several (newer) versions of the
product. Know errors will not return and your product will improve.
Continue reading...
no trackback
Monday 15 August 2011
By Esther Verlaan on Monday 15 August 2011, 16:30 - Maintenance Policies
Data corruption is one of the many reasons customers log issues. When the
amount of involved data is small it is smart to do it by hand. This is a task
of the Support Analyst not of the Maintenance Engineer. All changes need
to be logged so in case something went wrong the customer could go back to the
old situation.
Continue reading...
no trackback
By Jan Verlaan on Monday 15 August 2011, 16:27 - Maintenance Policies
Each product has a Product Life cycle. You have to inform your customers
upfront about the Product Lifecycle of your product. How long will the product
be supported by your organization is important to know for customers.
Lifecycle times depend on:
Continue reading...
no trackback
By Jan Verlaan on Monday 15 August 2011, 16:25 - Bug Report System
Performance can only be measured when performance related data is
available in the Maintenance System.
Master Data
When you like to measure the performance for Individual Maintenance
Engineers, Teams, Departments, etc, you need to have this data as master
data available in your Maintenance System. So your organization structure needs
to be somewhere in the Maintenance System. Same counts when you would like
to measure performance for Support, Customers and Product (versions),
service or feature packs, packages, modules, etc, as well.
Performance Data
Continue reading...
no trackback
By Jan Verlaan on Monday 15 August 2011, 16:21 - Bug Report System
As soon as the reported defect is registered and saved it should
go directly to the right Maintenance Queue. This can be reached by using a
automatic system that rotates based on the following information:
Continue reading...
no trackback
Tuesday 19 July 2011
By Esther Verlaan on Tuesday 19 July 2011, 22:05 - Solution Delivery
Depending on your Support and Maintenance policy you will provide certain
types of solutions and certain solution types definitely not.
There are several options. You could think of:
- Individual solutions (for all customers available)
- Weekly dumps
- Monthly dumps
- Collected Solutions
- Service Packs
- Individual solution on customer system
- Feature Packs (More for development)
Continue reading...
no trackback
By Esther Verlaan on Tuesday 19 July 2011, 21:58 - Bug Solving Proces
After you have pulled a reported defect of got one pushed, you start with
the analysis of the reported defect. You keep on working on the reported defect
until a solution is delivered. Re-work and hand-overs lead to longer waiting
time. The less hand-overs and the less re-work the lower the waiting time for a
customer.
Ask for help when the problem is not clear after analysis
After analysis (and reading design and development documents) the error
should have become clear. When this is not the case you have two options:
- ask the Support colleague who created the reported defect for help
- ask you Maintenance colleagues for help
It is up to you who you contact. When you are more experienced you know your
Maintenance and Support colleagues better to make a good choice.
Continue reading...
no trackback
By Esther Verlaan on Tuesday 19 July 2011, 21:49 - Bug Solving Proces
Your customer wants to receive quickly a good answer. To limit waiting time
an incoming reported defect must be checked as soon as possible.
Defect queues
Support provides defects based on their finding. To automate as much as
possible these request must end up on defect queues for Maintenance
Engineers to find. Routing should be done as automatically as possible to
speed up the process as much as possible. Routing could be done based on
the organization of Maintenance, often the following can:
Continue reading...
no trackback
Monday 18 July 2011
By Jan Verlaan on Monday 18 July 2011, 16:10 - Support Policies
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)
no trackback
By Jan Verlaan on Monday 18 July 2011, 16:07 - Support Policies
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...
no trackback
Last comments