A reporting system designed for compliance purposes and a reporting system designed for human use are not automatically the same thing.

The compliance function that designs a reporting system from the perspective of what it needs to receive — structured reports, categorised concerns, documented case files — will build something that functions well as a case management system. It may not build something that functions well as a channel people are willing to use.

The employee who is considering whether to raise a concern is not thinking about case management. They are thinking about risk. They are asking: will this be confidential? Will anyone know it was me? What happens next? Will I hear anything back? What if I am wrong? What if I am right? The design of the reporting system must provide credible answers to these questions — not in a policy document that the employee may or may not have read, but in the experience of using the system itself.

Design decisions that are made primarily for operational convenience — a reporting form that asks for the reporter's name as a required field because it makes case management easier; a process that does not provide acknowledgement of receipt because the volume does not justify it; a channel that is accessible only from a company device, on the company network — are design decisions that make the system easier to operate and harder to use. Every such decision reduces the population of employees who will use the system under real conditions.

"The reporting system that employees will actually use is the one that was designed from the perspective of the person considering whether to use it — not the person who will manage the cases it generates. These two perspectives are compatible, but only if the design process includes both."

Accessibility, confidentiality, anonymity, simplicity, and feedback.

Accessibility means that the reporting system can be reached from any device, at any time, from any location — not only from a company device or on the company network. The employee who wants to raise a concern while travelling, from home, from a personal device, or outside of working hours must be able to do so without any of these constraints creating a barrier. The concern that someone forms during a sleepless night at 2am must be raisable at 2am — because the willingness to report is often at its most acute in that moment, and a friction point that requires waiting until the next working day may be a friction point that prevents the report entirely.

Confidentiality is the assurance that the identity of the reporter will not be disclosed beyond those who need to know to manage the case. This assurance must be specific and operational: who will know, under what circumstances might that change, and what safeguards exist. A generic confidentiality statement is less effective than a concrete description of the process — who receives the report, what identifying information is visible to them, and under what circumstances it might be necessary to disclose the reporter's identity.

Anonymity is distinct from confidentiality, and both options should be available where possible. Anonymous reporting — where the system itself does not collect identifying information — provides a higher level of protection for reporters who fear that confidentiality could be breached. The limitation of anonymous reporting is that it prevents the case manager from seeking clarification, providing updates to the reporter, or closing the feedback loop. The solution is a system that allows anonymous reporters to check on the status of their report and receive communications through a secure, non-identifying reference number — maintaining anonymity while preserving some degree of two-way communication.

Simplicity means that the process of raising a concern is as frictionless as possible. A reporting form that is long, complex, or that requires the reporter to categorise their concern before they can submit it adds cognitive load at the moment when the reporter is already under stress. The form should ask for the minimum information needed to begin an assessment, with the opportunity to provide more detail as the case develops. The language should be plain, free of legal or compliance jargon, and should not imply that the concern needs to meet a specific threshold of seriousness to be worth submitting.

One of the most effective tests of a reporting system's usability is to have someone who is not in the compliance function attempt to use it, from a personal device, outside working hours, to raise a concern they are uncertain about. The friction they encounter — the number of steps, the fields they do not know how to complete, the uncertainty about what happens next — is the friction that real reporters encounter. The design improvements that emerge from this test are invariably more valuable than the improvements that emerge from internal review.

The design of the channel is itself a cultural signal.

The reporting system communicates something about the organisation's commitment to speak-up culture before any report is made. An anonymous hotline with a generic script and no organisational identity communicates that the reporting process has been outsourced — that the organisation has checked a box rather than built something it owns. A branded, well-designed channel with clear, specific language about how concerns are managed, what the organisation commits to in terms of process and protection, and who is responsible for overseeing the process communicates something different: that the organisation has thought carefully about this, that it takes it seriously, and that the channel is a real expression of how it wants to operate.

The training that accompanies the launch or relaunch of a reporting system is part of the same signal. Training that explains what the channel is and how to use it is useful. Training that explains why the organisation has built this system — what it believes about the value of concerns raised early, about the courage it takes to speak up, about the culture it is trying to build — is more useful, because it connects the mechanism to meaning in a way that pure instruction cannot.

"The reporting system is not just a channel. It is a statement about what the organisation values, what it protects, and what it does with information that people trust it with. Designing it as if it were only a channel produces a channel. Designing it as if it were a statement produces something that has a chance of building the culture it is meant to serve."

Download this article

Save a PDF copy for offline reading, or share it with a colleague who might find it useful.

Download PDF