Tuesday, 09:05, packing line 4. The label printer stops after every tenth carton. Lukas, the shift lead, is wearing gloves and holding a scanner. The nearest computer is in the supervisor's office, two halls away.
So he calls. Maintenance, the IT colleague, sometimes whoever picks up first. That's the right move, because a call is the fastest way to hand off an incident. It reaches the ticket system later, when someone has time. Or not at all, because the problem sorted itself out after half an hour and nobody thinks of it again.
This article is about why exactly this call is the most valuable moment of an incident, and how we capture it in IncidentLive with an incident hotline that IncidentLive answers. Lukas still does nothing but call, just one number instead of three different colleagues.
Why incidents still get phoned in
In manufacturing, logistics, facility management and every night shift, the phone is the number one reporting channel. Not because people don't know any tools, but because the situation calls for it:
- Hands are full. Someone securing a machine doesn't fill in a form.
- It's urgent. A call takes a minute, a complete ticket five to ten.
- You want someone to ask back. On the phone, the other side asks follow-up questions right away.
So the call isn't the problem. The problem is that it leaves no trace. Whoever picks up might jot something down on a note. The ticket gets created later, with the time it was created and in the words of whoever types it up. Who called, at what time and what exactly they said isn't recorded anywhere.
What's missing in the follow-up
While the incident is running, hardly anyone notices. In the follow-up, everyone does:
- In the 8D report, D2 asks when the problem first occurred and who noticed it. If the ticket says 09:48 because that's when it was created, the problem description is wrong from the start. More in our article on the 8D report.
- For a NIS2 notification, what counts is when you became aware of a significant incident. The early warning has to go out within 24 hours. Without a documented point in time, you'll argue afterwards about when the clock started.
- For root cause analysis, the first words often help more than any later summary. "Since about 09:05, after every tenth carton" is a clue. "Printer broken" in a ticket isn't.
How phone reporting works in IncidentLive
The flow is short on purpose. Lukas no longer calls maintenance or the IT colleague, he calls the incident hotline. That's one fixed number for all incidents: an internal extension, a saved contact in Teams or a number at Twilio. IncidentLive answers on the other end and asks three questions:
- What happened?
- What is affected?
- Since when?
He has up to a minute for each answer, ended by a pause or the hash key. Anyone who prefers to talk freely can leave a message of up to three minutes instead.
IncidentLive estimates the severity from what was said, for instance whether a line is down. Callers who want to set it themselves press a key from 1 (very urgent) to 4 (low). The team can change it at any time; the estimate is a suggestion.
A few seconds after hanging up, the incident exists:
- in Lukas's name, because his number is stored in his profile,
- with a title taken from his first sentence, not one a model made up,
- with the call as the first entry on the timeline, including time and wording.
Lukas gets the incident number by email so he can check later what came of it. If his colleague from line 5 calls five minutes later about the same printer, no second incident is created: the call is added to the open one.
From there, everything works like any other incident in IncidentLive. Alerts, tickets and notes land on the same timeline, coding agents report their findings via MCP, and anyone who wants to know the status asks the incident instead of calling Lukas again.
Who can create an incident
An incident hotline anyone can call is also an invitation. So a few fixed rules apply:
- Known numbers: Every user stores up to three phone numbers in their profile. Only calls from those numbers directly create an incident in their name.
- Unknown or withheld numbers create nothing. They go to triage, where your team reads what was said and decides whether it becomes an incident. Think of the external technician reporting at night that the cold store in hall 2 is climbing to 9 degrees.
- A call can do exactly two things: create an incident or add to an existing one. It doesn't close anything or change permissions. What should happen automatically afterwards is up to you (more on that below).
- Spoofed numbers get noticed. If someone uses a colleague's spoofed number to create an incident, the colleague gets an email about it.
On top of that, there's a limit of five calls per number per hour, so a false alarm stuck on redial doesn't flood the timeline.
Phone system, Teams or Twilio
You don't need a new telephony provider. IncidentLive connects in three ways:
- Your phone system via SIP, on premises or in the cloud, with an internal extension. The only requirement is that the system passes on the caller's number, not the switchboard's, otherwise IncidentLive can't recognise anyone.
- Microsoft Teams, for example through a saved contact. A call from Teams works like one from any other number.
- Twilio, if you want a dedicated number reachable from outside. It's one option, not a requirement.
With a phone system or Teams, calls can stay entirely inside your internal network. With Twilio, only the part that accepts calls needs to be reachable from outside.
Privacy on the phone
A call contains more than you'd think. That's why we handle it sparingly:
- Speech recognition runs locally by default on your servers, not in someone else's cloud. German or English, set per number.
- The caller's number is only stored truncated.
- Passwords and keys are filtered out before anything is stored. Whoever says "the password is …" on the phone won't find it on the timeline.
- With Twilio, a recording stays there only until IncidentLive has fetched it, and is deleted afterwards. Alternatively, you can use Twilio's speech recognition. Then nothing is recorded, but Twilio processes the words.
What phone reporting is not
IncidentLive is not an alerting or on-call tool, and it doesn't replace your ticket system. Phone reporting solves a narrower problem: the first sign of an incident often comes by phone, and that shouldn't get lost.
Of course, more can follow from a reported incident. Creating a ticket in Jira or GitHub, notifying whoever is on call, kicking off a workflow: all of that is possible. It just looks different for every team. Which incident wakes whom at three in the morning, which one can wait until the morning and which one needs a ticket right away depends on how you work. That's why there is no one-size-fits-all default. We set this up with you individually and first assess what actually helps you and what only adds noise.
It sounds small, but it pays off in the follow-up. The 09:05 call is on the timeline before anyone creates the first ticket. When D1 to D8 are later prepared for the 8D report or the early warning to the authority is due, the point in time is documented, with Lukas's own words next to it.
What this looks like in the interface and how to set up your incident hotline is shown on the page Report incidents by phone. For the pilot project, we set up IncidentLive on your servers and connect it to your phone system or Teams.