Incident management starts with a simple agreement: when a customer, user or colleague reports a problem, that report should end up in one place. For us, that place is Zoho Desk. An email becomes a ticket, an internal report can be logged manually, and replies stay attached to the same conversation. We do not want incidents to live in separate inboxes or in someone's memory.
That may sound administrative, but it is mostly practical. A ticket contains the report, contact details, status, communication and decisions made along the way. If another person needs to help later, they do not first have to reconstruct the story from hallway conversations.
Why this belongs in an SLA. Being ready to solve problems is one of the most important reasons a customer takes out an SLA (Service Level Agreement) with us. Software will occasionally break. What matters is that someone picks it up quickly, keeps you informed and makes sure the problem is resolved.
Four levels for the first assessment.
The first employee who sees a report classifies the ticket. That is not a final judgement forever, but it is the starting point for calm and proportionate handling. We use four basic levels:
| Level | Meaning |
|---|---|
| Critical / Kritiek | A problem in one of our products that prevents the majority of users from using it. |
| Severe / Ernstig | A problem that disrupts important processes and has no usable workaround. |
| Small / Gering | A small issue or mistake with limited impact on usability. |
| Change request / RFC | A request for functionality that does not exist yet, or for a change to functionality that is working as intended. |
In Zoho Desk we make the classification visible in the subject and priority. This is intentionally simple. The goal is not to create an impressive workflow diagram; it is to make sure everyone can quickly see what kind of report they are looking at.
The extra security question
In addition to the normal impact assessment, every incident gets a second question: could this affect the confidentiality, integrity or availability of customer data or Bronscode data?
If the answer is "possibly", we treat it as a potential security incident and escalate immediately. Not because every suspicion is automatically a disaster, but because the first phase matters. Well-meant investigation can change traces, expose data further or make the situation harder to understand.
That is why potential security incidents have a strict first rule: report what you see, then take no further action until the incident has been classified and a response plan exists. Do not keep clicking, delete anything or apply a quick patch "just to be safe". First determine what may be happening, who needs to be involved and what communication is appropriate.
Data breaches are a special case.
A data breach, in which personal or other confidential data may have reached unauthorised people, is a special kind of incident. We first assess what happened, which data is involved and whose data it is. We then inform you as the customer as soon as possible, even if we do not yet know everything, so you can decide in time what you need to do and which obligations you have. We keep a record of what we know and do, and take steps to prevent further exposure.
Communication is almost as important as the fix
A response to a ticket can take several forms: a quick fix, a clarifying question, an acknowledgement that we are working on it, a phone call or a message that the solution has been released. What fits depends on the classification, the expected resolution time and the agreements with the customer.
We see communication as almost as important as the fix itself. Not because talking fixes bugs — unfortunately — but because silence makes the problem feel larger for the person who reported it. A customer wants to know the report has been seen, what the next step is and whether anything is needed from them.
If communication happens outside the ticket, we summarise it in Zoho Desk. The digital ticket remains the system of record. In the office we also have the Bronsprinter: a small printer that turns every new support ticket into a physical slip. We really do pin that slip up and hand it to whoever is going to work on it. A fun side-note, but one that works.
Assign, resolve and close only when it is clear
After classification, a ticket is assigned based on product knowledge, urgency and available capacity. A small text mistake needs a different route from an outage in an important process. If a patch is required, we create an issue, review the change and release it through the normal production process. For heavier incidents that route may move faster, but it should not become careless.
A ticket can be closed only when it is clear that the problem has been resolved. Sometimes the customer confirms this. Sometimes the situation itself makes it clear. If not, we follow up first. For an RFC, closure is different: it is enough to explain that we will consider the request and record it in the right place for product work.
Follow-up and improvement. Each week we review resolved and open tickets so patterns and missed follow-up do not go unnoticed. As described in continual improvement, recurring causes and higher-priority incidents are revisited during the monthly quality day, and every improvement gets an owner so the same fire is less likely to return.