A support note is not enough when a file is at risk
In a law firm, a vague note like "system problem" tells support almost nothing. A proper incident log gives shape to the issue so the team can trace the sequence, compare it with other events and work out whether the problem sits in a template, a permission setting, an upload queue or a user workflow.
The point is not paperwork for its own sake. It is to protect the matter record and reduce guesswork when a deadline is close. If the log is thin, the investigation starts with questions that should already have been answered. If the log is clear, the support team can move straight to the likely cause and the affected area.
That matters in Sandton and across bigger offices too, where one matter team may be drafting, another may be reviewing evidence and a third may be preparing court bundles. A small interruption can spread quickly if nobody records exactly what was interrupted.
Record the facts that let someone trace the event
A useful incident entry reads like a careful note from someone who was watching the problem unfold. It should carry the essentials, in plain language, without trying to diagnose the issue too early.
- The time the issue was first noticed
- The matter name or matter number involved
- The user or team affected
- The screen, workflow or document step where it appeared
- What changed just before it started, if anything changed
- Any message, error code or unusual behaviour seen on screen
- Whether the problem blocked work or only slowed it down
Those details help separate a local user problem from a wider system issue. They also help when the same matter is handled by more than one office. A team in Pretoria may see the same symptom that Cape Town saw earlier in the day, and a good log makes that connection visible.
Impact should be written in working terms, not guesses
The strongest part of an incident log is often the impact note. Support teams need to know what the issue changed in practice. Did it prevent a template from generating, stop a bundle from uploading, delay a review queue or make a matter inaccessible to the wrong user group? That difference matters because each one calls for a different fix.
A clear impact note also helps firm ops teams set priority. If the issue is cosmetic, it can sit behind a live filing problem. If it affects evidence import or matter deadlines, it belongs near the top of the queue. The log should say how many users were blocked, and whether the blockage was total or partial.
- Blocked from opening a matter
- Unable to save a drafted document
- Search results missing key evidence
- Permission errors for one team only
- Repeated timeouts during upload
Writing impact this way keeps the conversation grounded. It stops a noisy complaint from being treated like a major failure, and it stops a serious matter from being written off as a small glitch.
Timing matters because support work follows a sequence
Every incident has a beginning, even if nobody sees it straight away. A support log should note when the problem was first noticed, whether it had been happening for a while and whether it appeared after a login, an import, a permissions change or a template update. That sequence can be the difference between a quick fix and a long search through the wrong area.
Timing also helps with deadlines. If a document failed to generate at 16:40 and filing was due the next morning, that is different from a minor issue discovered during a quiet review session. The record should show the period affected, not only the date. On busy weeks in Johannesburg firms, one afternoon of lost access can affect a bundle review, a matter handover and a client update all at once.
When load-shedding or a network interruption is involved, note that too if it is relevant to the actual event. The log should stay factual and not assume the cause. A good incident record leaves enough detail for someone else to rebuild the sequence later.
Affected users tell you whether this is local or wider
Support teams need to know whether one person is stuck or whether an entire group has been affected. That is especially important in firms where templates, review queues and permissions are split by department. If only one user cannot access a matter, the issue may be tied to that account. If five users in different teams see the same failure, the scope is broader.
It helps to record the team names and the roles involved, such as attorney, paralegal, legal secretary or operations staff. A permissions issue may only appear for a review user while the admin view looks normal. The same event can look very different depending on the role on screen.
POPIA-sensitive material also makes this careful approach worthwhile. When evidence or client records are involved, the log should note the affected area without copying unnecessary personal data into the incident trail. The goal is enough information to resolve the matter and protect the record, not a loose pile of details scattered through messages and chat.
A Sandton example from a busy evidence queue
Picture a mid-morning in Sandton. A litigation team opens its review queue and finds that three recent uploads are visible to one reviewer but not to the associate preparing the bundle. The matter is active, the deadline is close and nobody wants a long guessing session while calls are coming in.
A solid incident log would note the matter number, the time the issue was noticed, the users who could see the files and the step at which the problem appeared. It would also note that older evidence remained visible, while new uploads were not showing for one role. That distinction points support toward permissions or indexing, not a general system outage.
Because the record is clean, the team does not need to rebuild the story from scattered messages. They can see what happened, where it happened and who was blocked. That is the kind of note that turns a stressful support call into a workable investigation.
A log that helps later is better than a quick note now
Incident logging works best when the habit is shared. The person who spots the issue should capture the basics straight away, and the person handling support should keep the wording direct. Over time, the firm gets a record that can be searched, compared and used to spot repeat patterns in templates, matters or permissions.
The best logs are not long. They are complete enough to answer a few plain questions: what failed, when did it start, who was affected and what was the business impact. Once those are clear, the rest of the investigation is easier to manage and easier to close off properly.
For law firms handling deadlines across Johannesburg, Pretoria, Cape Town, Durban and Bloemfontein, that discipline is not a nice extra. It is part of keeping work visible, evidence organised and support issues under control.
