A Complaint Is a Feeling. An Incident Is an Event.
A complaint can be answered with an apology and a credit. An incident has a timestamp, a location, possibly witnesses, possibly damage, and possibly a claim form in its future — a field technician’s dropped ladder, a missed SLA on a business-critical contract, a delivery that destroyed a client’s equipment, an altercation at an event. These call for a different document: not a ticket, but a record. One written while memories are fresh, evidence is attachable, and the sequence of events can still be established.
This CSI form template is that record. It serves operations teams, field service businesses, venue operators, and B2B account teams — anyone who must document a service failure or operational event thoroughly enough that it survives scrutiny: a client dispute, an insurance claim, a post-incident review, or a contract negotiation six months later.
Who’s Filing Shapes What Matters
The form opens by establishing the reporter and their relationship to the event: the contact details of the person filing, and their role via multiple choice — the affected client, the staff member present, the field technician, a witness, or a manager reporting on someone’s behalf. A client’s account and a technician’s account of the same event are different documents; knowing which one you’re reading is the first requirement of using either.
The Timeline Comes Before the Story
Incident records live on sequence. When did it happen — or when was it discovered, which is often the more honest question? Captured as a date field, with the location and any existing ticket or job references alongside. Then the account itself in a long text field, with a prompt that produces usable narratives: what happened, in order, including what was done immediately afterward. The immediate-response detail — first aid administered, power isolated, the client notified — is routinely the most consequential paragraph in the file.
Witnesses, While They Still Remember
Human memory decays in days; disputes take months to arrive. The form captures witness names and contact details at filing time — staff, other customers, bystanders — so statements can be taken while recollections are sharp rather than reconstructed at claim time from whoever still works there.
Evidence, Attached at the Source
Photos of damage, the delivery note with the wrong signature, the email chain, the sensor log export — a file upload field takes them all in the same sitting as the narrative. Evidence attached at capture carries a timestamp that evidence forwarded later never quite shakes the suspicion of. A yes or no question on whether injuries occurred or third-party property was damaged flags the cases that need insurers or legal involved — early, while options still exist.
Classify Now, Pattern-Read Later
An incident type from a dropdown — service failure, property damage, delivery failure, conduct, SLA breach — does two jobs at once: it routes the record to the responsible manager today, and it builds the dataset that reveals patterns next quarter. The same response archive that resolves this week’s case will, filtered by type and site, show the recurring failure your operations review needs to see. Completed records can flow into your claims or case system through webhooks, access stays with the managers who own them via role-based permissions, and auditors or insurers can be granted read-only viewer access without touching the working files. Operational record-keeping like this sits beside the business forms collection and the IT templates library.
Frequently Asked Questions
What is a customer service incident form?
A formal record of a service failure or operational event — timeline, people involved, witnesses, evidence, and classification — thorough enough to support a dispute, an insurance claim, or a post-incident review long after the event itself.
How is an incident different from a complaint?
A complaint expresses dissatisfaction and seeks a remedy. An incident documents an event: what happened, when, to whom, with what damage, and who saw it. Many incidents also generate complaints — but the incident record is the factual layer that determines liability, claims, and prevention.
Who should be able to submit one?
Anyone close to the event: affected clients, front-line staff, field technicians, and witnesses. The reporter-role question keeps each account attributable, and allowing multiple filings about the same event is a feature — parallel accounts strengthen the record.
What evidence belongs in the file?
Whatever exists: photographs of damage, delivery documents, correspondence, system logs, and witness contact details. Attach at the time of filing — evidence gathered weeks later is weaker evidence and a weaker defense.
How long should incident records be kept?
Longer than feels necessary: claims and disputes commonly surface months or years after the event, and limitation periods vary by jurisdiction and claim type. Set a retention policy with your legal advisor, then let the archive hold the records untouched until it says otherwise.