Contact Management Overview

Contact Management is a tool that lets you manage interaction between you, your customers, your potential customers, even your fellow company members.

The system has many powerful features and capabilities. We outline these in this overview, which has the following main headings:

Once you are comfortable with the contents of this overview, you should work through Contact Management setup in this help file. This will familiarise you with initial setup options, as well as elements you need to design and create before you can start capturing incidents.

Contact Management Concepts


An incident is one or more contacts with the same person or company about a specific event.

We need to look at this definition in a bit more detail. What do we mean by a specific event? Suppose you have a customer who has purchased a washing machine
from you:

  • The customer telephones you to ask when you will be installing the washing machine. You ask the customer which times are convenient, and you tell the customer that you will call them back.
  • You then consult with your delivery department and obtain a suitable time for delivery. You telephone the customer back and schedule the delivery.
  • The customer phones you the next day to say that the delivery time you arranged is not convenient, and suggests a different time. While the customer is waiting, you contact the delivery department, and they agree to the revised time.

The above three actions are all related to one incident, the installation of the washing machine. Many times, one action is sufficient to complete, or close, an incident. In other cases, there can be many actions before you can close an incident.

A few days later the same customer telephones to say that the washing machine is leaking. This is now another incident. It has nothing to do with the installation incident.

You can have multiple open incidents for the same customer at the same time. For example, you are a salesperson selling a complicated piece of machinery to a potential new customer:

  • The customer’s electrician emails a question to you regarding the power requirements of the machine. You send an email to your technical department and you inform the electrician that you will reply to their query once you obtain the details.
  • You then get a telephone call from the technical manager asking about the warranty on the machine, and you answer the question.
  • You then get another email from the same technical manager asking you to provide a schedule for delivery, installation, and training. You reply, saying that you will have the schedule available by Friday.

These are three separate incidents happening simultaneously. The second incident required one action, while the other two are ongoing.

The whole contact management process concerns handling and managing incidents.

In order to manage and control the process, the system logs any action you perform on an incident. For example, you open an incident and you assign John Smith in the customer’s company as the contact person. Later, you realise that you actually spoke to John Peterson. To change the contact name you perform an action on the incident. The system logs this as a new action on the incident.

Customers and People

Customers are your actual or potential customers. If you create customer records, you have the option of linking incidents to customers.

If you use customer contracts, which we discuss a bit later, then you must use customers, since contracts link to customers. However, even if you do not use contracts, using customers gives you an important benefit: you can monitor each customer’s queries, as well as your customer service level.

Sometimes you deal with one person only in each company. Other times, you may deal with many people in the same company. In the example above, the salesperson was dealing with the electrician and the technical manager.

You can create a record for each person you have contact with, and you link that person to his or her company. You can also link a person to more than one company. For example, you may have a consultant who provides support and training for your products to many of your customers.


Agents are the people in your company who deal with incidents. You create each agent, and then assign incidents to these agents. However, you cannot assign incidents to inactive agents.

In some organisations, the process of assigning agents to incidents is simple, in others complex. If, for example, you are using the system in one department of your company to handle one type of incident, the process is relatively simple. On the other hand, you may have different departments such as sales, finance, and technical support, dealing with a myriad of products, and thousands of interactions with customers or potential customers daily.

The system provides tools and methodologies to help you manage your process, whether simple or complex, in the most efficient way.

Agent Groups

You group agents together into agent groups. Agent groups allow you to pool resources with a common skill into one group, and then assign relevant incidents to that group. This is a powerful management tool.

You can group agents by the functions they perform (sales, support), by the product skills they have (washing machine, tumble dryer), or by a combination of both (washing machine sales, washing machine support, tumble dryer sales, tumble dryer support). It all depends on how you need to manage the incident flow.

You can assign an agent to more than one agent group – an agent could easily have knowledge in more than one agent group. In addition, you may wish to assign an agent to multiple groups as a supervisor.

Escalation Groups

One of the most compelling reasons to use the system is its ability to ensure that agents deal with incidents within acceptable timeframes. Customers regard taking too long to respond as bad service, and responding within agreed time limits as good service. Of course, not responding at all is very damaging to your company’s image.

You use escalation groups to control timed responses to incidents. They work like this:

  • An escalation group consists of one or more agent groups arranged in sequence, with a timing factor between each successive agent group. For example, you create an escalation group called “Widget Product Support Escalation” that has two agent groups: “Widget Support Personnel” and “Supervisor.” The timing factor between these two groups is set to 180 minutes.
  • A customer who owns a widget phones in for support. An agent creates and saves an incident. Depending on your setup, the agent can assign the incident to an escalation group, or the system can automatically assign the incident to the escalation group. The incident now sits with the “Widget Support Personnel” agent group, the first one in the escalation group.
  • If an agent resolves the query with the customer within the 180-minute time limit, they close the incident, and that is the end of it.
  • However, if after 180 minutes the incident is still open, the system escalates the incident to the “Supervisor” agent group. The supervisor then takes appropriate action.

There can be any number of agent groups in the escalation group. For example, you can add another group that contains the technical manager as an agent after the supervisor group, and another one that contains the CEO of the company after that.

If an agent asks a customer for information, and then has to wait for the customer to respond, the agent can enter a due date for the incident and it will not escalate until after that. (This too is an option – you can force escalation irrespective of the due date.)

An agent can also transfer an incident out of their escalation group and into another. For example, the customer asks a question about a widget that the agent cannot answer. There could be an escalation group called “Advanced Product Support” into which agents can transfer incidents. Since the system logs the transfer itself, agents know that they cannot transfer incidents without good reason.

The Working Calendar

We spoke about escalating incidents after a certain amount of time. The system only counts time during normal working hours. Therefore, in order for the system to escalate correctly, it has to know the operational hours of the company – what days of the week agents work, and what hours they work each day.

You give this information to the system by filling in the working calendar. Besides the regular hours, you can also define public holidays or any days that agents do not work.


When you create an incident you assign a priority to it, and you can report and see incidents in priority sequence. You can change the priority of an open incident at any time. You can create as many priorities as you wish.

Incident Types

The system has another element, an incident type. Incident types classify incidents based on their content. You name an incident type by its function, such as “Widget Support.” You can link incident types to escalation groups, although this is not mandatory. Why have incident types? Why can you not link an incident directly to an escalation group? There are two reasons:

  • Escalation groups and agent groups are internal structures within your organisation. You may need to reorganise these structures frequently, in terms of resources that you have available to you. Incident types, on the other hand, are more permanent. They refer to products and/or services you provide.
  • Incident types allow you to force strict control of another important feature in the system: paid contracts.

Incident Type Groups

You may find that you create a large number of incident types, especially if you use contact management features in different areas of your organisation. In this case, agents may find a long list of incident types, within which they then have to select the incident type they need.

You can reduce the size of the incident type list by categorising incident types into groups, called incident type groups.

An incident type can belong to only one incident type group.

When an agent processes a new incident, they can select the incident type group, and the system presents only incident types that belong in that group to the agent. In addition, you can then assign an incident type group to an agent by default, so that the agent then chooses an incident type immediately, and only relevant incident types display.

The use of incident type groups is optional. If you do not use incident type groups, then agents choose from the complete list of incident types.


Workflows are an additional control mechanism you can use to control authorisation of incidents. We will look at workflows in the processing section of this overview, since you will understand their functionality better once you understand the incident processing cycle.

Sales Force Automation

Sales Force Automation is an additional feature set that helps you focus on the sales process. We will look at this feature set and its elements in the processing section later in this overview.

Contract Templates and Contracts

If you use the system to track sales activities, you do not need to worry about charges for incidents. The same applies if you provide free information or a free support service, or an internal company service.

However, if you do charge for support services, the system can help control this. You can specify per incident type whether it requires a contract. If it does, then you cannot create an incident of this type for a customer unless they have a valid contract.

Contracts can be of different types, such as annual, per incident, time-based, and so on. You can have more than one contract per customer.

There are many more types of contract available than you would typically use in any one organisation. To simplify the creation of contracts, you can create contract templates. A contract template contains just about all the information required for a contract. Once you create contract templates, creating an actual contract consists simply of choosing a contract template and then a customer.

If you use the Annuity Billing add-on module, you can link contracts into the annuity billing system to automate regular invoicing of customers. For details about this module, click here.

The Document List

You can place documents in a shared folder called the document list. The system allows all agents to view these documents at any time. Documents can be any type of file such as word processing, spreadsheet, or graphics files.

You can attach documents from the document list to incidents, contracts, and knowledge base articles. You use the document list as follows:

  • You link documents to incidents if you need to provide additional, detailed information to a customer. You can email the incident to the customer and include documents from the document list as attachments.
  • Customers can in turn email attachments to you. The system adds them to the document list and links them to the incident.
  • By making a shared repository available to agents, the system encourages knowledge sharing. For example, a salesperson prepares a presentation to a potential customer. If the salesperson puts a copy of the presentation in the document list, other sales people can adapt it for their use.

The Knowledge Base

The knowledge base lets agents create articles. In these articles, they can share information with each other about support, sales, or any other issues. In addition, agents can link documents from the document list into knowledge base articles.

You can create up to five separate sets of text for each article. This lets you distinguish, for example, diagnostics from solutions, or create advanced information for more qualified personnel.

Since knowledge base articles are records in a database, you can use the standard database search utility to find words or phrases within them. This powerful search facility lets new and relatively inexperienced agents quickly find information relevant to the incident they are dealing with. There is also an advanced search facility.

To further assist agents to find relevant articles quickly, you can categorise knowledge base articles using up to five hierarchic levels of categories.

The knowledge base is particularly useful in product support departments. Once an agent solves a problem for a user, they can document this very quickly in a knowledge base article, thereby making the information available to their colleagues.

Inventory Items

You may have many inventory items that are the subject of incidents. If so, there may be value in tracking incidents per inventory item. You could see trends in problem areas, requests for improvements, diversity of usage, and so on.

The system lets you create an inventory database with relevant fields. You can optionally assign an inventory item to each incident.

Mandatory Items

We have worked through a number of concepts and methods, and you may be starting to get concerned about how much work this all looks like.

In fact, this is not the case. Firstly, the only mandatory requirement when you create an incident is the incident type and either the escalation group or the agent. All the rest of the fields can be optional, depending on the amount of control you need.

Secondly, many of these fields can be set automatically from other fields. For example, you create an incident and choose a customer. If there is a contract for the customer, the system defaults to the contract. The contract selects an incident type, which in turn selects an escalation group, which in turn selects an agent group, which in turn selects an agent! The full spectrum of control and management can be in place automatically. This is why it is essential that you understand these concepts and play with the system before you start using it.

By the way, with most of the automatic selections, you can choose whether to allow agents to override them when they create an incident. This again depends on your particular structure and requirements.


Processing Incidents

Flexibility and Control

Contact management processing revolves around incidents. Depending on your company structure, you can adopt different processing methods. We strongly recommend that you learn the system’s features before you start processing actively.

The first issue we look at is the balance between flexibility and control. Here are two examples at the opposite end of the spectrum:

  • Your salespeople develop their own sales leads. They go out to potential customers and they use the system to manage their interactions with their customers. In this case, the salespeople would create and maintain their own incidents. A sales manager can monitor their performance by looking at the open incidents.
  • You are selling and supporting a number of products and/or services. Potential customers contact you for information, and existing customers contact you for support, for which they have to pay. You would receive many queries by phone, fax, and email. You have to receive the queries, create incidents, and assign each one to the correct incident types and/or escalation groups and/or agents. You use escalation groups to ensure that agents dealt with incidents on time.

The fact that there are so many different circumstances means that the system has to be as flexible, or as rigid, as you require. Using the above two examples:

  • In the first example, sales people do not have to create customers, contracts, and escalation groups. All they have to do is create an incident, give it an incident type, an agent, and a heading (outline), and log actions. The system accepts an incident without requiring any additional fields – they are all optional.
  • In the second example, the support personnel cannot support a customer unless they have a current support contract. In addition, the system must route the incident to the correct set of agents who know the product the customer has. In this case, the system, following your setup rules, will take control and set the incident type, escalation group, and even choose a particular agent to handle the incident. In many of these cases, you can get the system to enforce decisions so that agents cannot override them.

Naturally, you may need to combine these situations, and have flexibility in some areas and strict rules in others. In what follows, we show how you can exercise control over incident handling. Once you understand where you can exercise control, you can marry the system’s features with your company requirements, and arrive at the optimal methodology for your organisation.

Incident Types

Incident types classify incidents based on their content and on which agents have to deal with the incident. The incident type is the springboard from which processing begins. This is how it can work, if you fully automate the system:

  • When you create an incident, you specify an incident type.
  • The incident type links to an escalation group.
  • The escalation group in turn assigns the incident to an agent group, and optionally moves the incident after a specific time into further agent groups.
  • Agent groups consist of agents. For each agent group you tell the system how to assign incidents to agents in that group.

The incident type allows you two types of control:

  1. You can force each incident into the escalation group you set up. This ensures that incidents escalate correctly, according to your business rules.
  2. You can require a customer contract for the incident. This ensures that only customers who have a current contract can use this incident type.

If you use both of these features on incident types that require contracts, you have a very strict control mechanism:

  • When the agent creates an incident, all they need do is identify the customer and their contract. The system will route the incident to the correct escalation group.
  • If no contract displays for the type of support the customer is seeking, they do not have a current contract.
  • The agent cannot skip the customer and/or contract field and assign the incident to the incident type, because the incident type requires a contract.

Incident Life Cycle

You create a new incident. At the creation phase, you select one or more of the customer, contract, incident type, escalation group, and agent fields. You can choose a contact person as well as other fields. You enter a summary outline as well as detailed information. If the workstation you are on has Microsoft Office spell-checking software installed, you can spell check the incident details.

If you complete the incident, you can close it. Closing an incident means that there is no follow-up required or expected. However, this is not necessarily the end of the incident. For example, a customer contacts you with a problem, and you give him the solution and close the incident. The customer contacts you the next day because your solution did not work. You can then re-open the incident.

If follow-up is required, the source of the follow-up can be the agent or the customer:

  • You may undertake an action such as to research a problem, or provide a potential customer with some information that is not at hand. You can then enter a date by which you undertake to respond. Until that date has passed, the incident will not escalate.
  • You may request the customer to perform an action or try a potential solution and then report back to you. You can at the same time email the incident to the customer’s email address, the person’s email address, or both.

Whatever the source of the follow up, you save (post) the incident without closing it. You can set its priority.

If you need assistance on the incident, you can proceed in a number of ways:

  • If your organisation makes use of the document list and/or knowledge base, you can attach documents and/or knowledge base articles to the incident. You can also search the knowledge base.
  • You can assign the incident to another incident type, escalation group, or agent, if the system is set up to allow these transfers.
  • You can email the incident to someone else and request assistance. This could be another agent, or a specialist in the company who is not an agent.

The system calls the process of opening an incident, making a change of any nature, and then posting (closing) the incident, posting an action for an incident. The system logs all actions. Anyone can see the history of this incident at any time.

If your organisation uses escalation, and you do not deal with the incident within the escalation period for the escalation group, the system moves the incident to the next agent group in the escalation group. This, too, is an action that appears on the incident.

The fact that the incident is now in another escalation group and assigned to another agent, does not exclude you from working on the incident. If, for example, you were waiting for feedback from the customer, and the customer contacts you, you can still access the incident and continue. If necessary, you can transfer the incident back into your escalation group.

We talked about email earlier on. You can email an incident, with the last action or all actions, with or without its linked documents, and with or without the knowledge base articles, to the customer, the person you are dealing with, another agent, anyone else, or even the whole escalation group.

Once you post an incident, you can retrieve it in many places. For example, on the Customer Maintenance screen, in the Incidents tab, you can see all incidents for the customer.

The two most common ways of retrieving incidents are:

  • You can use the My Incidents function to see all your open incidents.
  • The most powerful and sophisticated entry point to existing incidents is the Incident History function. This lets you sort, group, and search incidents using sophisticated filters.

Archiving and Purging Incidents

Over time, you will accumulate many incidents. Depending on the nature of your company’s activities, you may or may not wish to keep these incidents. The system offers you two levels of control as regards older incidents:

  • You can archive incidents. The system does not include archived incidents in the incident reports. However, you can view the archived incidents and restore incidents if you need to do so.
  • You can purge (delete) some or all of the archived incidents.

You use the powerful incident history filter to choose which incidents to archive, un-archive, or purge.


Workflow Processing

You can control the flow of incidents through the system using a number of methods. You use the method(s) that suit your organisation best:

  • You can allow agents to post new actions to incidents and close them whenever they like
  • You can use escalation groups to control how long an agent can leave an incident unattended to before the system escalates it to another agent group
  • You can use workflows, with or without escalation groups, to obtain an agent’s authorisation to close an incident, after optionally first moving the incident through a hierarchy of authorisations

Workflows allow you to process incidents on an authorisation basis. You can use workflows, for example, to control purchase orders for raw materials. Here is a typical example:

  • In the first step, the manufacturing division creates an incident because they are going to run short of a raw material.
  • The buyers in your organisation receive the incident, and they obtain prices for the raw material. Once they obtain prices, they approve the incident, which sends it to the second step.
  • In the second step, the incident goes to the costing department to determine the impact, if any, on the selling prices of items that use the raw material. If the impact is too great, the costing department rejects the incident, which sends it back to the buying department. The buying department then looks further for prices, and approves the incident again, sending it back to the costing department. Once the costing department are satisfied, they approve the incident, which sends it to the third step.
  • In the third step, the incident moves to the accounting department to place the order. The accounting department has all the pricing and contact information available in the incident itself, and they place the order. They also obtain a delivery schedule from the supplier. Once they do so, they approve the incident, which sends it to the fourth step.
  • In the fourth step, the incident returns to the manufacturing department, this time to the project manager, who uses the information to determine the manufacturing schedule. Once the project manager has the information that is required, and approves the incident, the incident closes automatically, because there are no further steps.

You implement workflows in a very simple manner:

  • First, you create workflow steps, which correspond to the steps in the above example.
  • You then create a workflow, in which you link the workflow steps in sequence. You also set which agent, agent group, or escalation group is responsible
    for that step.
  • Once you create a workflow, you link it into an incident type.
  • When you process an incident and use an incident type that links to a workflow, the system uses the workflow steps automatically.

You can use the same process to supervise and manage sales leads, manage the release of products to customers, track project benchmarks, and so on. Workflows can function together with escalation groups if you require it. Escalation groups ensure that agents handle incidents on time. You can link each workflow step to an escalation group if you need to. The system will escalate the incident within the escalation group, but keep it in the same workflow step until an agent authorises it.

Using workflows and escalation groups together gives you exceptionally powerful management control of your business processes. In addition, since the escalation group and workflow rules exist independently of each other and independently of incidents, you are able to constantly refine and enhance these processes.


Sales Force Processing

The Contact Management module handles interactions with customers and potential customers for any type of interaction, including, for example, sales, marketing, and support activities.

The Sales Force Automation feature adds sales-specific control and management processing to the general contact management process. This helps agents and managers to focus on, and report on, the exact stages of the sales opportunities in a company.

Instead of managing sales solely via incidents, you instead create a sales opportunity. Each sale of one or more items to an existing or prospective customer is a sales opportunity. While you can still use the incident aspect of a sales opportunity to ensure timely follow up and so on, the sales opportunity allows you to specify and track the actual sales process on an individual basis. It also allows you to prepare standard quotes for customers.

The Sales Force Automation feature makes use of a number of elements, which we now look at:

Opportunity Status

The status lets you track the success or otherwise of each sales opportunity. Once you win a sale, you would then want to invoice and close the sales opportunity. This status field controls this.

Opportunity Stage

Opportunity Stages let you define discrete stages of the sales process. You change the opportunity stage in the sales opportunity as the sale progresses. Each time you change a stage in a sales opportunity, the system generates an incident.

Prospective Customers

When you process a sales opportunity, you link it to an existing or prospective customer. You can maintain a prospective customer database. If you achieve the sale, you can convert the prospective customer into an actual customer and convert the quote into an invoice.

Competitors and Competitor Products

You can create a database of competitors and their products. This lets you track where competitors are active, and how successful you are against them. The use of competitors and/or competitor products is optional.

Opportunity Source

Opportunity source codes allow you to analyse the source of your leads. For example, you can create codes for different type of advertising, for user referrals, and so on. You obtain this information when you make first contact with the customer or potential customer. The use of source codes is optional.

All these elements come together in the Sales Opportunity function, which is where you process your sales.

To use the sales opportunity function

  1. Each sales opportunity is a distinct record. You can adjust the opportunity stage and/or status at any time. Each time you change the opportunity stage, the system creates a closed incident for tracking purposes.
  2. You link the sales opportunity to an existing or a prospective customer. You can create and modify one or more quotes for the customer from within this function. Only one of these quotes is active at a time.
  3. You can link competitor information, including information about competitor products. You can specify the amount each competitor is quoting your customer or potential customer.
  4. You can link documents from the Document List to the sales opportunity.
  5. You can use account manager security to allow agents to keep their prospective customers and sales opportunities private. No other agents, except for supervisors, can view private customers and sales opportunities.
  6. If the sales opportunity results in a sale, you can invoice the customer from this function. The system will convert the active quotation into a sales order or an invoice. If you are using a prospective customer, you can convert the prospective customer into an actual customer automatically. All customer details, quotes, invoices, and incidents move across to the customer record.
  7. If the sales opportunity is not successful, you can close it and then keep it and use it for analysis purposes.
  8. If you need to, you can reopen a closed sales opportunity at any time.

You can use the sales force charts and reports to view your sales opportunities in multiple ways.

My Calendar / My Contacts

You can create contacts who can be agents, employees, customers, people on your people database, or any other third party.

You have a calendar that you can use to schedule events. You can link contacts into the schedule. If the contacts are other agents, you can examine their calendars to see when they have free time. When you create an event for yourself that you link to another agent, the system updates the other agent’s calendar as well.

You can set your calendar to give you reminders about events ahead of time.


The Evolution Services Function

We have spoken about the fact that escalation groups escalate incidents after a set amount of time, without specifying how this actually happens. The mechanism is a stand-alone utility that ships with the system called the Evolution Services function.

The Evolution Services function performs two important tasks for you:

  • It can escalate incidents.
  • It can retrieve email and convert emails into incidents.


The Evolution Services function reads all open incidents, checks their times of update against the timings in the escalation group, and, if necessary, moves incidents into the next agent group. You tell the Evolution Services function how frequently to perform this process. You can escalate every few minutes, every day, or you can manually initiate an escalation. Clearly, you have to run the Evolution Services function if you wish to use escalation. No escalation occurs except through the Evolution Services function.


You can give customers and/or potential clients email addresses to send queries. The Evolution Services function can check these email addresses, intercept the emails, and turn them into incidents. This powerful tool allows you to feed customer queries into the system on a controlled and automatic basis. If the Evolution Services function finds the sender’s email address in the customer or people database, it will also assign the incident to the customer or person automatically.

The email feature makes a good impression on your customers and potential customers. If you have a large volume of contact management traffic, this feature speeds up the allocation of incidents to the correct agents considerably. It can also dramatically reduce your administration costs. To configure this feature, you create additional email addresses in your company. These email addresses are for the system’s use only. For each email address, you specify information such as which database it links to, the incident type, and the escalation group.
You can therefore create separate email addresses for sales and support, or for specific sales and/or support areas. The closer you model the email addresses to your contact management structure, the more accurate the assignment of incidents is.

You can also set up an automatic response to the email. This will send a reply to the sender. You could say, for example, that you will respond to the email within two working days. You tell the Evolution Services function how frequently to check for email. You can check every few minutes, every day, or you can manually initiate a check. Naturally, you will want the system to respond promptly at any time, so you would run the Evolution Services function 24 hours a day if you use the email feature.

Besides handling new queries, you can also use the Evolution Services function’s email handling for ongoing incidents. We mentioned earlier in this overview that you could mail an incident to a customer or a person. If you do so, the email contains the incident reference number. If the customer or person replies to the email and leaves the original email unchanged, the Evolution Services function will update the incident with the customer’s reply.

This means, in effect, that the system contains all the tools you need for a completely automated email help centre.


Reports and Enquiries

Since management of the contact management function is one of the prime reasons for using it, the reporting and enquiry functions form a prominent part of day-to-day processing:

  • Supervisors and managers have instant access to the current state of play.
  • Managers can use feedback from reports and charts to re-allocate resources depending on the actual, live situation. For example, if a particular agent group has too many incidents to handle, a manager can simply add new agents from less active agent groups into the busier agent groups.
  • Agents themselves get to see all outstanding incidents allocated to them. They can group these by priority, date due, product types, customer, or any number of criteria. They do not have to spend time looking for what to do next.
  • All incidents are visible to everyone at any time. This principle, combined with the system’s ability to group incidents in any way, allows personnel in your organisation to use incident data in many ways:
    • Supervisors can optimise escalation groups and agent groups to provide maximum efficiency.
    • Supervisors can identify inefficient agents by looking at incident closing statistics, and agents with inadequate skills by looking at assignments of incidents to other agents.
    • Customer relationship personnel can see incidents grouped by customer, and can gauge service levels and identify potential hotspots.
    • Product developers can see incidents grouped by product, and can analyse this information to detect product or documentation weaknesses, as well as directions for product development.