Said out loud, it arrives sooner and disappears sooner, because the listener is already doing something else; written down, it stays — but only if the company has a place where things get written.
An issue log — also called a problem log — is the list where problems are recorded the moment they are noticed, with the details that allow someone else to pick them up: when, who saw it, what happened, where, and with what effect.
It applies to the professional who works with two team members, to the person responsible for a department and to whoever runs a company of eighty people: the number of lines changes, not the mechanism.
An issue log isn't there to help you remember: it's there to get the problem out of the head of the person who saw it, at the moment they see it, in a form someone else can take ownership of.
Below: what it should be distinguished from, why problems that are seen rarely reach the people who could act on them, the eight fields of a useful entry, the cycle that keeps it alive, the criteria for priority and the mistakes that empty the log.
What an issue log is and how it differs from a list of complaints
Are a list of problems and a list of complaints written the same way?
No, and the difference lies in three elements a complaint doesn't have: an observable fact, a verifiable effect, and a status that changes over time.
The Treccani Italian dictionary defines a register as the book in which acts, facts, operations and data "are recorded or noted in a given order" [1].
In company work the core remains — recording facts in chronological order — and the object changes: the problems someone notices while working, from the customer called back twice about the same delivery to the machine that stops at every changeover.
You recognize a log entry by how it's written: "the supplier delivered without a delivery note, three times in two weeks, and each time the goods sit in receiving for half a day" is an entry; "receiving is a mess" is a complaint.
The first can be taken on; the second can only be shared.
There are four tools to distinguish it from.
The nonconformity log records failures to meet a requirement and follows its own rules, often within a quality system: in Italy there were 101,426 active ISO 9001 certificates as of December 31, 2024 [7], and if you have one, the path is the one described in nonconformity management.
The meeting minutes record what was said on a given date, not what happens in the department on Tuesday at eleven.
The to-do list contains activities that have already been decided, while the log contains facts about which nobody has decided anything yet.
The suggestion box collects proposals, that is, answers, and answers are evaluated with other criteria — the subject of business improvement proposals.
The issue log sits upstream of all four: it's the place where a problem exists before anyone knows what to do about it.
Why problems seen on the floor don't reach the people who can act on them
Do a problem worked around in two minutes and a problem written down have the same outcome?
The same outcome for the current shift, two opposite outcomes for the following month: the first disappears with whoever worked around it; the second remains available to whoever can change the condition.
A problem worked around is not a problem closed: it has stopped being visible and keeps costing where nobody is looking. The log is there to get it out of the head of the person who saw it, at the moment they see it, in a form someone else can take ownership of.
The clearest measurement comes from field research in nine American hospitals: 239 hours of observation of 26 nurses and 194 failures recorded as they happened, 166 of which were classified as problems [5].
In 93% of those problems the response was to get hold of what was missing and carry on, without informing anyone and without looking for the cause; only 7% of the responses reached the threshold of a report to someone who could act, and that threshold had been set with admittedly generous criteria [5].
The authors' estimate: an average of 33 minutes lost per eight-hour shift working around snags [5].
The research comes from health care, where work can be observed minute by minute: it points to a mechanism, not a frequency that can be transferred to a department or a professional practice.
The second reason concerns people who would gladly mention the problem, and don't.
An exploratory American study of 40 employees documents the phenomenon: the large majority of interviewees report at least one occasion when they didn't feel comfortable raising an issue they considered important with their manager, and some explain their silence by the belief that speaking up wouldn't have changed anything [6].
The sample is too small for the proportions to count as a measurement: it shows which reasons recur, not how widespread they are.
That silence isn't fixed with one more form: it depends on the consequences people who speak up expect, and it is the territory of psychological safety, without which the log remains an empty column.
The Italian context adds its own factor: in 2022, 80.9% of Italian companies with at least 3 employees were controlled by an individual or a family, and in most cases management is entrusted to the business owner or a family member [4].
Where management runs through a single person, the list of problems coincides with what that person manages to see in a day.
Practical element: ten minutes spent writing down the problems of a single area — goods receiving, invoicing, a new team member's first day — bring out more of them than get named in a meeting: this is a guideline from our editorial team, not a measured figure.
The log widens the filter not because people become more attentive, but because what they notice has a place to go.
The step that comes first is noticing the problem: that is the craft of problem finding in business.
The eight fields that make a problem report workable
What must an entry contain for someone else to work on it?
Eight fields, and there are few precisely because the entry has to be written standing up, at the moment the problem is seen.
The structure isn't an editorial invention: the model that INAIL, Italy's national workplace injury insurance institute, offers companies for near misses separates the description of the event, location, possible causes, damage assessment and actions, and closes with a summary that brings together the person responsible, the deadline for acting and verification [3].
The same document distinguishes two moments that companies tend to confuse: the report, written by whoever saw it, and the analysis, by whoever takes it on [3].
Translated outside the scope of safety, an issue log entry holds these eight fields.
| Field | What goes in it | Typical mistake |
|---|---|---|
| Date and time | when the problem was noticed, not when it is written | putting it off until the end of the day: by six in the evening, three entries out of eight are left |
| Reported by | the name of the person who saw it, so you can ask for details | anonymous reporting out of habit, which makes it impossible to reconstruct the facts |
| What happened | the observable fact, in one sentence, without interpretation | writing the presumed cause instead of the fact |
| Where | department, workstation, stage, customer or case involved | "in production", which narrows nothing down |
| Effect | what it cost: time, material, a customer who called back | an adjective instead of a measurement ("serious", "heavy") |
| Priority | high, medium, low, assigned by the reviewer and not by the reporter | leaving it to the writer: everything becomes high |
| Status | open, in progress, closed, with the date of the status change | a log where everything stays "open" |
| Owner and date | one person and a deadline, not a department | "to be assessed", which is not an owner |
Fields 1-5 are filled in by whoever saw the problem, in less than a minute; fields 6-8 are filled in by whoever reviews the log, because priority and responsibility are decisions, not observations [3].
An entry written this way also holds up when it moves to an analysis method: if the problem is recurring and measurable, those five fields are already the statement from which the 5 whys technique starts.
Who writes, when it's reviewed, what happens next: the log cycle
Who writes, how often is it reviewed, what does the person who reported get back?
The first two questions have short answers; the third decides whether the log survives its second month.
Anyone who sees a problem writes, with no role filters: the log is there to widen the set of eyes beyond those of the people in charge.
It's reviewed at a fixed rhythm, in a short window that is always the same — twenty minutes a week, new entries read one by one — and the rhythm matters more than the duration (an operational guideline from our editorial team, not a measured figure).
The reviewer assigns priority, status and owner, that is, the three fields that are not up to the reporter.
On the third point, INAIL's procedure for reporting near misses is explicit, and it applies beyond the scope of safety: the person who reported receives three distinct responses — acknowledgment, progress ("the report has been taken on by the purchasing department") and the final outcome [2].
The same document identifies the lack of feedback as one of the two barriers that in practice prevent incidents from being recorded in Italy, together with the fear of "snitching" [2].
The weekly cycle fits into four moves.
- Read the new entries, one by one, without discussing their merits: the only purpose is to check whether the fact is clear.
- Assign priority, status and owner to the entries that need them.
- Send three responses back to the reporter: acknowledgment, progress, outcome [2].
- Reread the entries closed the month before, to check that the problem hasn't come back.
In a family-owned machining company with about twenty employees, where the business owner moves between the office and the shop floor several times a day, the log lives where the work happens: a sheet hung near the line gets filled in while the machine restarts; a file on the office computer gets filled in at the end of the shift, which means almost never.
For people who work alone or with a couple of team members the cycle is the same: the review becomes an appointment with yourself, and it separates the moment of observing from the moment of deciding.
When it's done as a group, the discipline of effective business meetings applies: agenda, stated duration, minutes.
From entry to priority order: choosing the three problems to take on
With forty open entries, which three do you take on?
The ones that rank highest on three criteria read together: how often the problem recurs, what it costs each time, and how much of its cause lies within the company's boundaries.
The third criterion is the one most often forgotten, and it's the one that prevents months spent on conditions the company can't change.
A log that grows without hierarchy has the same effect as an empty log: whoever reads it doesn't know where to start.
Damage assessment and expected frequency are explicit fields in the INAIL model too, which asks you to estimate the event's impact and its repeatability relative to work cycles [3].
The three criteria are applied in this order.
- Frequency: how many times the entry has appeared in recent weeks, counted on the log and not from memory.
- Effect: hours lost, material, delayed deliveries, customer callbacks — the field that was already a measurement in the entry.
- Controllability: if the cause lies in a document, a handoff or a tool within the company, the problem can be tackled now; if it lies outside, it gets logged and monitored.
Three open problems at a time is a reasonable ceiling for a small company: it's an operational guideline from our editorial team, born of a practical constraint — whoever reviews the log also has a job to do.
The fourth problem doesn't disappear; it stays in the queue with its status and moves up when one of the three is closed.
When there are dozens of open entries and the first two criteria are enough, the ranking can be done once with a Pareto chart, which arranges categories by weight and shows which few items make up most of the total.
When the choice between two entries remains uncertain even after the three criteria, the way forward is to make it explicit with a decision matrix, which weights the criteria instead of leaving them to the impression of the moment.
For entries that come back identical weeks apart, the log has already done its job: it signals a structural problem rather than an episode, and from there you move into organizational problems.
The mistakes that turn an issue log into a notepad
What turns a log into a notepad or a list of complaints?
Five habits, and four out of five can be recognized by looking at the log itself, without asking anyone anything.
The log that looks for whoever is to blame. When the "what happened" column fills up with names, the log has changed jobs.
INAIL describes this drift as a "progressive blaming of workers in lower hierarchical positions", up to the overuse of the expression "human error", and points to the alternative reading: the event is an opportunity for improvement, and the question is why that action was able to produce that effect [2].
The signal: entries written by others drop to zero within a few weeks, and only those of the people in charge remain.
The log with no response. Entries go in and nothing comes out: no acknowledgment, no outcome.
This is the condition in which one of the recurring reasons for silence appears, namely the belief that speaking up is pointless [6], and it isn't fixed by asking for more reports: it's fixed by giving back the three responses the cycle calls for [2].
The signal: no entry has an acknowledgment date later than its report date.
The log that collects answers instead of facts. An entry that says "we need a second scanner" is already a proposal, and it hides the problem it should describe.
The fix is to rewrite the entry as fact and effect — how many times the line formed, how many minutes — and treat the proposal for what it is.
The log that grows and never closes. Without the status field and the monthly reread, the list becomes an archive of things everyone knows about that have been stuck for a long time.
The signal: no entry has changed status in the last month.
The one-person log. If it's filled in only by the person who already saw the problems before, the log hasn't widened anything: it has moved onto a sheet what used to be in one head.
The signal is arithmetic: how many different people appear in the "reported by" column in a month.
Bringing a problem to the surface remains the uncomfortable part of the job, and it's the only part that produces new information: a company that logs many problems isn't worse off than one that logs few — it's simply looking.
Limits and conditions of applicability
The data on how people behave when facing work snags come from research conducted in hospitals [5], where work can be observed minute by minute: the percentages point to a mechanism, not a frequency measured in Italian companies.
The study on organizational silence is based on 40 interviews in the United States [6]: a small sample, useful for recognizing the reasons for silence, not for quantifying them in another context.
The INAIL models cited were developed for near misses and hazardous situations [2] [3]: the reporting structure is transferable, while legal obligations on workplace safety remain a matter in their own right and are not fulfilled by an internal log.
An issue log doesn't produce any improvement on its own: it makes the information available to whoever can decide, and from that point on the result depends on the decisions.
In peak weeks — a large delivery, a sudden absence, a tax deadline — the weekly review gets skipped: it's better to say so and resume it than to pile up entries nobody reads.
Where a certified management system already exists, the issue log doesn't replace the procedures it requires: it sits alongside them upstream, on facts that can't yet be classified as nonconformities.
FAQ
What is an issue log?
It's the list where problems that are noticed get recorded as they happen, with the date, the person reporting, the fact, the location and the effect.
"Issue log" is the most common name; it's also called a problem log or an issue register.
Its purpose is to make the problem available to whoever can take it on, not to preserve a memory of it.
What's the difference between an issue log and a nonconformity log?
The nonconformity log records failures to meet a requirement and follows the rules of the management system it belongs to.
The issue log sits upstream and also records what doesn't violate any requirement: waiting times, duplicated steps, information that arrives late.
The two coexist, and an issue log entry can become a nonconformity after analysis.
Who should write in the issue log?
Anyone who sees the problem, with no role filters: the log exists precisely to widen the set of eyes beyond those of the people in charge.
Priority, status and owner, on the other hand, are assigned by the reviewer, because they are decisions and not observations.
How often should an issue register be reviewed?
A short, fixed rhythm works better than a long, occasional review: twenty minutes a week, always at the same time, is an operational guideline from our editorial team.
Regularity matters more than duration, because regularity is what ensures that whoever reports gets a response within a predictable time.
Do you need software to log problems?
No: a shared spreadsheet or a paper template in the department easily handles the first few months.
The real constraint is that there is a single place, reachable by the people doing the work — not that it is digital.
Operational summary
An issue log collects observed facts, not impressions: every entry says when, who saw it, what happened, where and with what effect.
The first five fields are filled in by whoever notices the problem, in less than a minute and at the moment they notice it; priority, status and owner come later, from the reviewer.
The review is a short, fixed appointment, in which new entries are read one by one and you decide what gets worked on.
Every review sends three responses back to the reporter: acknowledgment, progress, outcome.
The problems to open are chosen on three criteria read together — how often they recur, how much they cost, how much of their cause lies within the company's boundaries — and are kept to a few at a time.
Closed entries are reread a month later, because a problem that comes back says something the first intervention hadn't seen.
The log is judged by two numbers you can read in ten seconds: how many different people wrote in it in the last month, and how many entries changed status.
Conclusion
An issue log isn't an archive of what's wrong: it's the way a problem stops belonging to the person who saw it and becomes an entry someone else can take ownership of.
Eight fields, a single place to write and twenty minutes a week to reread are enough; the rest is what goes back to the person who reported, and that is the part that decides whether the log will live past its second month.
If you want to train your eye before the template, you'll find the craft of noticing in problem finding in business; if you see the same entries come back identical every month, you're reading a structural symptom, and the next step is organizational problems.
After a few months of written entries, the subject of conversations in the company changes: people discuss dated, measured facts instead of impressions, and meetings get shorter because the list is already on the table.
The person in charge stops being the only one who sees, and you feel this in the days before you see it in the numbers: problems arrive smaller, sooner and with less tension, because naming them has become a normal act and not an admission of guilt.
Sources and references
[1] Treccani, «registro», Vocabolario on line, Istituto della Enciclopedia Italiana. Available at: https://www.treccani.it/vocabolario/registro/
[2] INAIL – Contarp, Csa, Dimeila (with Utilitalia and Fondazione Rubes Triva), «Gestione degli incidenti. Procedura per la segnalazione dei near miss», 2021. Available at: https://www.inail.it/content/dam/inail-hub-site/documenti/2021/03/Gestione%20degli%20incidenti%20near%20miss.pdf
[3] INAIL – Dimeila, Guglielmi A., Pellicci M., de Merich D., «Documento tecnico. Metodologia di analisi dei near miss (mancati infortuni) e delle situazioni pericolose. Linee guida e Istruzione operativa», November 2025 edition. Available at: https://www.inail.it/content/dam/ricerca-e-tecnologia/documenti/area-salute-sul-lavoro/2026/01/LineeGuida_modello_Condivido_def.pdf
[4] ISTAT, «Censimento permanente delle imprese 2023: primi risultati», report of November 14, 2023 (reference year 2022; about 280,000 responding companies, representative of 1,021,618 companies with at least 3 employees). Available at: https://www.istat.it/comunicato-stampa/censimento-permanente-delle-imprese-2023-primi-risultati/ — PDF: https://www.istat.it/it/files/2023/11/REPORTCensimprese.pdf
[5] Tucker, A. L., Edmondson, A. C., «Why hospitals don't learn from failures: organizational and psychological dynamics that inhibit system change», California Management Review, vol. 45, no. 2, 2003, pp. 55-72; Harvard Business School working paper version 03-059 (November 6, 2002), read for this article. Available at: https://www.hbs.edu/ris/Publication%20Files/03-059_12b5444c-de66-4935-a12d-9a9b3688f62d.pdf
[6] Milliken, F. J., Morrison, E. W., Hewlin, P. F., «An exploratory study of employee silence: issues that employees don't communicate upward and why», Journal of Management Studies, vol. 40, no. 6, 2003, pp. 1453-1476; author's version read for this article. Available at: https://w4.stern.nyu.edu/emplibrary/Milliken.Frances.pdf
[7] Accredia, «ISO Survey 2024: le imprese accelerano su sostenibilità e digitalizzazione», AccrediaHub, October 30, 2025 (ISO data as of December 31, 2024). Available at: https://www.accredia.it/comunicazione/accrediahub/iso-survey-2024-le-imprese-accelerano-su-sostenibilita-e-digitalizzazione/