Problem management: stop solving the same incident ten times over

A problem in KairosLink is a root cause that groups tickets. Instead of closing ten incidents with the same explanation pasted in, you open a problem, link those ten tickets to it, and the investigation gets a life of its own, with its number, its status, its assigned technician and its dates. When the cause is gone, closing the problem offers to resolve, in one go, the tickets that are still open.

Every problem carries a sequential number of its own within your organization, in the format P-organization-0001, generated under a lock that guarantees two technicians creating a problem in the same second will not step on each other's number.

Six statuses that describe the investigation, not the technician's mood

There are six statuses and they are fixed: identified, investigating, root cause identified, workaround available, resolved and closed. The listing shows the problem count in each status, and also filters by affected customer and by text over the number and the title.

Dates are stamped on their own as the problem moves: detection, root cause identified, resolution and closure. The root cause date is written the first time the problem reaches that status or a later one, and it is not reset if the problem is reopened later: it measures how long the team took to understand the problem, which is the number that matters.

Priority uses the same scale as tickets, with four levels: low, normal, high and urgent. An urgent problem reads exactly like an urgent ticket and there is no criteria to translate between screens.

Tickets and problems link from both sides

From the problem you search tickets by number or subject and link them; from the ticket detail you search the problem and link it there. It is the same relationship seen from both sides, so a technician inside a ticket never has to leave to find anything. A problem groups many tickets, and a ticket can belong to more than one problem.

If the problem does not exist yet, you create it straight from the ticket: the form arrives with the title and the customer already filled in, and on save that ticket is linked. The search always excludes what is already linked, so links are never duplicated.

Access is controlled with four separate permissions: view, create, edit and close. A technician can investigate and document a problem without having the authority to close it and drag the customers' tickets along with it.

Closing offers to resolve the tickets, it never closes them on its own

When you close a problem, the screen lists the linked tickets that are still open and you tick which ones should be resolved. The ticked ones receive one shared resolution message as a reply visible to the customer, and move to Resolved. The ones you do not tick stay exactly as they were.

Nothing closes silently: with no resolution message no ticket is touched, and a problem that was already closed is not closed again. The customer never sees a ticket change status without a reply explaining it.

The customer sees the workaround, never the investigation

The problem has two fields of its own: the root cause and the workaround. When the status is workaround available, that text is what the team has to answer with while the cause is still standing.

With the problem in that status and the field filled in, that workaround shows up on its own in every portal ticket linked to that problem, in a block of its own above the conversation. The customer opens their usual ticket and finds the way to keep working right there, without any technician copying and pasting it into every reply.

That is the only thing that crosses over. The root cause, the internal problem title, its number and the tickets of the other affected customers stay on the panel side: your customer never learns their incident is one of twelve. And if the problem has no workaround filled in, or its status is another one, the portal ticket looks exactly as it always did, with no empty block and no heading announcing anything.

The root cause ends up in an article, not in a loose field

From the problem you link an already published knowledge base article, or you generate a new draft with one click. That draft is not written by an artificial intelligence: it is assembled from the fields you already filled in, in three sections (symptom, root cause and workaround), and the fields you left empty show up flagged as missing information, so the draft never looks finished when it is not.

The draft lands as a draft with internal visibility, in its own category, and the problem is left pointing at that article. Publishing it and deciding whether the customer can see it is always a person's call.

A report that measures the investigation, not the feeling

The Reports section has a problem management report of its own, filterable by customer and by date range, with the last 90 days loaded up front. At the top, six numbers for the period: problems opened, problems closed, average time from opening to root cause identified, average time to closure, linked incidents, and problems with a workaround available.

Below that, the distribution across the six statuses and the detail problem by problem: number, customer, status, how many incidents it groups and the three dates that matter, opening, root cause and closure. The average of incidents per problem sits next to the total, and it is the number that tells you whether you are really grouping or opening one problem per ticket.

Times come out in hours and are calculated over the dates the flow stamps on its own, not over a manual entry. The report exports to CSV, with one row per problem, and to PDF with your organization's logo and without KairosLink branding, so it goes to the customer exactly as it downloads.

Problem management is included in Business and Enterprise.

Frequently asked questions