Bridge Calls & Escalation

1📞 Running Bridge Calls & the Incident Commander

A bridge call is a conference call created during significant incidents so multiple teams can troubleshoot together — on Microsoft Teams, Zoom, Webex, Google Meet, dedicated incident management platforms, or enterprise telephony. Large organisations may have dozens of people on a bridge; without structure, these calls become chaotic.

Many organisations assign an Incident Commander or Major Incident Manager. Their job is usually not to personally fix the technical problem — it's to coordinate the response: controlling the bridge, maintaining focus, assigning actions, requesting updates, tracking timelines, coordinating teams, managing escalation, and communicating with stakeholders. A technical engineer should cooperate with this structure rather than working around it.

2📋 Structured Investigation & Action Logs

The person running the call should quickly establish: what happened, when did it start, what is affected, what is not affected, what changed, what teams are required, and what troubleshooting has already been completed. For example: "We are investigating a login outage affecting the customer portal. The incident began at approximately 09:10 UTC. Users can access the website, but authentication fails after submitting credentials. The application, IAM, network and database teams are currently engaged." This immediately gives everyone context.

A common problem during bridge calls is several people speaking — and troubleshooting — simultaneously. Good incident management assigns specific actions to specific teams, then has each team report back:

Network team:    Check connectivity between application subnet and identity service.
IAM team:        Review authentication logs.
Application team: Capture request and response details.
Database team:    Validate connection pool and query performance.
SOC:             Confirm whether any security controls are blocking traffic.

Someone should also maintain a running action log:

09:05 Incident declared
09:08 IAM team joined
09:11 Authentication servers confirmed healthy
09:16 Network team identified packet drops
09:22 Firewall policy review started
09:31 Incorrect firewall rule identified
09:37 Rule corrected
09:41 Authentication success confirmed
09:48 Monitoring stable

This timeline becomes extremely useful later — for incident reports, root cause analysis, management updates, lessons learned, and compliance evidence. Avoid vague open questions like "Does anyone have any ideas?" — direct specific questions to specific teams ("Network team, can you confirm whether TCP 443 succeeds between APP01 and IDP01?"), and periodically summarise what's already been ruled out so people don't re-investigate the same areas.

3📤 Escalating Incidents Properly

Escalation does not mean forwarding a ticket with "Please investigate urgently." Good escalation should make the next engineer productive immediately. A useful escalation package contains: issue summary, business impact, environment, timeline, expected behaviour, actual behaviour, troubleshooting completed, evidence collected, recent changes, current hypothesis, and what assistance is required.

Issue:
Users intermittently fail MFA authentication.

Environment:
Production / Authentication Service 8.7 / Windows Server 2022 / F5 load balancer

Impact:
Approximately 30% of authentication attempts fail.

Started:
12 August 2026 approximately 14:10 UTC.

Expected:
Users should receive an MFA push notification.

Actual:
Authentication request remains pending and eventually times out.

Troubleshooting completed:
- authentication servers restarted individually
- database connectivity confirmed
- push provider connectivity confirmed
- DNS resolution confirmed
- packet capture completed
- issue reproduced across multiple users

Findings:
Failed requests are visible in the authentication server logs but no
outbound notification request appears.

Recent changes:
Configuration patch applied approximately two hours before the incident.

Evidence attached:
- application logs, authentication logs, packet capture, screenshots,
  configuration export

Request:
Please review why notification processing stops after request creation.

4↑ Escalation Levels: Functional vs Hierarchical

Many global organisations use levels such as L1 (Service Desk), L2 (Technical Support), L3 (Senior Support/Engineering), and L4 (Development/Product Engineering) — though terminology varies: Tier 1/2/3, Engineering, Product Support, R&D, or Vendor Support. The key concept is that escalation transfers the problem to someone with deeper expertise or different authority.

There are two distinct escalation types:

• Functional escalation — moving the issue to a more specialised technical team, e.g. Help Desk → Network Team → Firewall Team.
• Hierarchical escalation — escalating management attention because of business impact, SLA risk, regulatory concern, executive visibility, or major customer impact, e.g. Support Engineer → Support Manager → Director → Executive Management. Technical ownership may not change at all — only who's aware of it.

5🚩 Severity, Priority & Timezones

Large organisations often classify incidents by severity — commonly P1/Critical, P2/High, P3/Medium, P4/Low — though definitions vary between companies. A P1 typically represents a widespread outage, a critical production service being unavailable, a severe security incident, or substantial financial or operational impact. Never exaggerate severity simply to receive faster support — it erodes trust in your reports over time.

Always specify timestamps and timezone. "The issue started at 9 AM" is ambiguous once London, New York, Singapore and Sydney teams are all reading it. Write "The issue started at 09:00 UTC" or "09:00 CET / 08:00 UTC." UTC is usually preferred for technical investigations and log correlation, since it removes any need for the reader to do timezone math.