7 ting dit Teams Phone nødopkald skal kunne før du sover roligt igen

De fleste tror Teams automatisk klarer 112 helt rigtigt. Det gør det ikke.

Jeg har efterhånden siddet med et par SMV’er, hvor man først fik sved på panden, da nogen spurgte: “Hvis jeg falder om på lageret, hvordan ved 112 så hvor jeg er?”. Stilhed. Og så det klassiske: “Jamen, vi bruger jo Microsoft, så det er vel på plads?”.

I den her artikel går vi lige omvendt til værks. Vi starter med, hvad der faktisk skal ske i virkeligheden tirsdag formiddag kl. 10, når nogen ringer 112 via Teams Phone. Og så bygger vi en simpel, men seriøs plan derfra.

Teams Phone nødopkald vs gammelt fastnet – hvad er forskellen?

Forestil dig jeres gamle omstillingsanlæg med fysiske bordtelefoner. De stod fast på skrivebordet. Nummeret var knyttet til en bestemt adresse, og måske endda til et bestemt kontor.

Nu har du Teams Phone. Folk sidder:

• på kontoret
• hjemme i køkkenet
• på et coworking space
• hos en kunde
• i toget med laptop og mobil hotspot

Samme Teams-klient. Samme virksomhed. Helt forskellige steder.

Forskellen er ret simpel: I fastnet-verdenen var “hvor du er” indbygget i kablet. I Teams-verdenen skal du designe det.

Den korte sammenligning: gammelt vs Teams

Det er derfor cloud-VoIP og Teams-telefoni kræver lidt mere omtanke, når vi taler sikkerhed og compliance. Ikke fordi teknikken er farlig, men fordi fleksibiliteten gør det nemt at få blinde vinkler.

4 begreber du skal have styr på, før du rører ved 112 i Teams

Du behøver ikke hele Microsoft-ordbogen. Men du slipper ikke helt for et par begreber. Jeg lover at holde det i menneskesprog.

1. Emergency calling

Det her er bare Microsoft-sprog for “nødopkald”. Det dækker over:

• at kald til 112 (og andre nødnumre, hvis I har internationale brugere) behandles særligt i Teams
• at der bruges specielle regler for routing og adresser

2. Emergency address

En emergency address er den fysiske adresse, der skal sendes til alarmcentralen sammen med opkaldet. I Danmark typisk noget i stil med:

• Firmanavn
• Vej, nummer, etage, evt. side / hus
• Postnummer og by

Det her er “minimum”. Hvis I har større lokationer, giver ekstra info rigtig god mening: bygning, fløj, lager vs kontor osv.

3. Location / Place

Addressen er gaden. Location er mere præcis placering inde i huset. Microsoft bruger lidt forskellige ord (Location, Place), afhængigt af opsætningen, men pointen er:

• Samme adresse kan have flere lokationer (fx “Bygning A, 2. sal” og “Lagerhallen” på samme vejnummer)
• En bruger eller et netværk kan knyttes til en bestemt lokation

4. Routing

Routing er bare telefon-vejen ud af huset. I Teams Phone-sprog:

• Calling Plan: Microsoft er også teleoperatør
• Direct Routing: I har egen trunk/operatør koblet op mod Teams
• Operator Connect: en slags “Direct Routing as a service”

For nødopkald er spørgsmålet: Hvilken vej sendes kaldet ud, og forstår operatøren, at det er et 112-kald med adresseinformation?

5 scenarier jeres Teams Phone nødopkald skal dække

Det her er stedet, hvor mange konfigurationer vælter. Man tænker “kontor” og glemmer, at folk ikke sidder pænt på række ved faste skriveborde længere.

Scenarie 1: Fast kontoradresse

Standard-situationen. Brugeren sidder på jeres hovedkontor, på jeres wifi, ringer 112 fra Teams-klienten på pc.

Her vil du typisk:

• knytte jeres interne netværk (LAN/VLAN/wifi) til en bestemt emergency address + location i Teams
• sørge for, at alle brugere, der typisk arbejder der, har den adresse som “hjemmebase”

Scenarie 2: Hjemmearbejde i Danmark

Jeres medarbejder sidder hjemme i rækkehuset i Hvidovre, på sit eget wifi, men ringer 112 via jeres Teams Phone-løsning.

Her er der to veje:

• I vælger, at nødopkald skal gå via mobiltelefonens eget SIM (og ikke Teams) hjemmefra
• eller I understøtter at brugeren kan sætte sin hjemadresse som emergency address i Teams

Det første er tit det nemmeste at få stabilt, hvis folk alligevel har firmamobil. Men det kræver en klar politik og instruktion: “Brug din mobil-apps native opkaldsfunktion til 112 hjemmefra”.

Scenarie 3: Mobil, SIM og Teams

Her bliver det hurtigt rodet, hvis du ikke er skarp: En medarbejder har Teams Phone på mobilen, men også et normalt mobilabonnement på samme enhed.

Hvis vedkommende ringer 112 fra telefonens almindelige opkaldsapp, går det typisk korrekt til nærmeste alarmcentral via mobilnettet, som vi kender det. Men ringer de 112 fra Teams-appen, går kaldet gennem jeres Teams-telefoni setup.

Min anbefaling i de fleste SMV’er er klar: Nødopkald på mobil skal gå via mobilnettet, ikke via Teams Phone. Sig det højt til brugerne, og sørg for at IT og ledelse er enige om politikken.

Scenarie 4: Reception og fællesområder

Receptionen er klassikeren. Her står måske en fysisk Teams-telefon eller en pc, som mange bruger. Hvis der sker noget i receptionen eller kantinen, er det ret afgørende, at:

• nødopkaldet har den rigtige adresse og lokation
• interne nøglepersoner får besked i sekundet efter, at der er ringet 112

Derfor ser man ofte sær-regler for receptionister og frontdesk-telefoner i moderne omstillingsanlæg og receptionstelefoni.

Scenarie 5: Call queues og autosvar

Her er misforståelsen: “Hvis der er kø på vores kundeservice, kan de vel bare ringe 112 midt i køen”. Det kan de, men kun hvis jeres design tillader det.

Det I skal undgå, er alt der ligner:

• nødopkald, der lander i en kø eller et autosvar
• en receptionist, der uden at vide det sidder som “mellemmand” på et 112-kald

Test det. Ikke i hovedet, men i virkeligheden. Mere om det om lidt.

Hvem ejer adresserne? 3 roller du skal udpege

Det her er ikke kun et IT-projekt. Hvis det er IT, der tilfældigt skriver adresser ind i Teams-portalens felter fredag eftermiddag, så har I en tikkende compliance-bombe.

Jeg plejer at dele det op i tre roller. Kald det RACI-light, hvis du absolut skal have konsulentsprog på det.

1. Ejeren (typisk IT-chef eller driftsansvarlig)

Ejeren er den, der kan stå på mål for, at designet er fornuftigt:

• godkender, hvordan I gør med hjemmearbejde vs kontor
• beslutter, hvilke lokationer der oprettes
• sørger for, at der findes en skriftlig nødopkaldspolitik

2. Datakilden (typisk HR, Facility eller administration)

De ved, hvor folk sidder. Og hvornår I flytter.

• leverer opdaterede adresser på kontorer og lokationer
• melder ind, når I får ny etage, ny fløj eller nyt lager
• kan hjælpe med at beskrive lokationer, så det giver mening for beredskab

3. Teknikeren (Teams / telefoni-ansvarlig eller leverandør)

Teknikeren oversætter beslutningerne til Teams-konfiguration:

• opretter emergency addresses og locations
• kobler netværk, brugere og policies korrekt sammen
• planlægger og gennemfører tekniske tests

Hvis I kun er 20 mennesker og har én kontoradresse, kan de her roller godt være samme person på papiret. Men sørg for, at alle tre “kasketter” faktisk bliver tænkt igennem.

Teams Phone nødopkald – forskelle på Calling Plan og Direct Routing

Der er et vigtigt skel her: Hvem håndterer den sidste del ud mod alarmcentralen?

Calling Plan: Microsoft som teleoperatør

Med Calling Plan er det Microsoft, der både leverer Teams og selve telefonilinjen.

Det betyder typisk:

• nødnumre som 112 er foruddefinerede i systemet
• adresse-information sendes som en del af opkaldet, hvis du har sat emergency addresses korrekt op
• nogle lande har særlige krav og features, som kan være dokumenteret i Microsofts landespecifikke vejledninger

Fordelen for en SMV er, at du ikke skal koordinere med flere leverandører om selve 112-signalet. Ulempen kan være mindre fleksibilitet, hvis du har meget specifikke krav eller blandede landesæt.

Direct Routing: egen eller tredjeparts trunk

Med Direct Routing har du en Session Border Controller (SBC) et sted i ligningen, og en operatør, der leverer linjer ind til Teams.

Her skal du have styr på to ting:

• Teams-konfigurationen af emergency calling
• operatørens og SBC’ens håndtering af 112 og adresse-information

Her støder jeg oftere på, at man antager, at “operatøren nok har styr på det”. Måske. Men I skal kunne få et klart svar på mindst:

• Hvordan sikrer I, at 112 bliver route’t korrekt, uanset hvilket nummer der ringer fra Teams?
• Hvordan håndteres adresse-information (Location Information)?
• Hvad sker der, hvis kaldet kommer fra en international bruger / udenlandsk nummer?

Skriv svarene ned. Helst i jeres generelle runbook for telefoni og sikkerhed og compliance i erhvervstelefoni.

6 testcases du skal køre, før du sætter flueben ved “Teams Phone nødopkald ok”

Nu kommer den del, hvor vi går fra teori til “tirsdag kl. 10”.

Jeg vil stærkt anbefale, at I koordinerer test af 112 med jeres operatør eller følger deres anbefaling for nødtest (nogle har specielle testnumre eller procedurer). Du skal ikke ringe direkte til 112 og lave rollespil uden forudgående aftale.

Men som minimum skal I igennem følgende scenarier. Der hvor 112 ikke kan ringes i test, kan du ofte nøjes med at teste, at det rette routingmønster, policy og adressevalg slår igennem i Teams og på trunk’en.

Test 1: 112 fra kontor-pc på hovedkontoret

Mål:

• Bekræfte at kaldet route’s til det rigtige nødnummer via korrekt trunk/plan
• Sikre at emergency address for hovedkontoret anvendes

Sådan gør du:

• Brug en testbruger, der repræsenterer en almindelig ansat på hovedkontoret
• Tjek i Teams-administration, at brugerens emergency policy er korrekt
• Test efter aftale med operatør / brug evt. dedikeret testnummer

Test 2: 112 fra reception / frontdesk-enhed

Mål:

• Sikre at receptionens fysiske enhed bruger den rigtige lokation (fx “Bygning A, reception”)
• Verificere at eventuelle interne notifikationer udløses korrekt

Her kan du samtidig tjekke, at receptionspersonalet ved, hvad de skal sige og gøre, hvis de ringer 112 for nogen andre.

Test 3: 112 fra laptop på gæste-wifi i kontorbygningen

Mål:

• Tjekke om I adskiller gæste-wifi og interne netværk i Teams’ emergency mapping
• Sikre at en ansat på gæste-wifi stadig har en fornuftig nødopkaldsvej

Nogle vælger, at nødopkald fra gæste-wifi ikke skal gå via Teams, men i stedet håndteres via mobil. Så skal den beslutning være kendt og beskrevet.

Test 4: 112 fra hjemmearbejdsplads via pc (VPN on/off)

Mål:

• Se hvordan Teams opfatter placeringen, når brugeren er hjemme
• Tjekke om VPN påvirker nødopkaldsrouting utilsigtet

Har I besluttet, at 112 ikke skal ringes via Teams hjemmefra, så test i stedet, at mobiltelefonens native 112-adfærd fungerer som forventet, og at brugerne ved, hvad de skal.

Test 5: 112 fra mobil med både Teams og mobilsignal

Mål:

• Bekræfte jeres politik: Hvilken vej skal brugeren gå?
• Tydeliggøre adfærd: “Brug altid den almindelige telefonapp til 112” eller lignende

Her handler testen mest om mennesker og kommunikation. Kan folk svare rigtigt på: “Hvis du står på gaden med din mobil og skal ringe 112, hvad gør du så?”.

Test 6: Simuleret nødopkald under kaldkø / kundeservice

Mål:

• Sikre at telefonister kan lave nødopkald, selvom de sidder i kø eller aktivt kald
• Bekræfte at deres nødkald ikke behandles som almindelige kundeopkald

Her kan I nøjes med simulationskald, hvis operatøren ikke tillader rigtige 112-tests. Pointen er at se, om de kan:

• afbryde nuværende kald
• starte et direkte udgående kald til nødnummeret uden at ryge tilbage i kølogikken

Drift: 3 faste tidspunkter hvor Teams Phone nødopkald skal med på tjeklisten

Det er ikke nok at sætte det op én gang. Verden flytter sig, og det gør jeres kontorer også.

1. Hver gang I flytter, bygger om eller udvider

Når Facility eller ledelsen siger: “Vi får to ekstra lokaler på 3. sal” eller “Vi flytter lageret ud i nabobygningen”, så skal der ringe en klokke hos jer.

Tjekliste:

• Skal emergency address opdateres, eller skal der laves ny?
• Er wifi / LAN i de nye lokaler mappet til en location i Teams?
• Er der særlige risici (produktion, lager, maskiner), der kræver mere præcis lokation?

2. Én gang om måneden: mini-driftskontrol

Det behøver ikke være tungt. 15-30 minutter kan gøre meget.

• Se, om der er kommet nye brugere uden emergency address
• Tjek tilfældigt udvalgte brugere for korrekt policy og lokation
• Gennemgå leverandør-/operatørbeskeder for ændringer i nødopkaldsprocedurer

Hvis du alligevel har en generel driftstjek for jeres Teams Phone, så lad nødopkald være et fast punkt, som i en lille mini-runbook, ligesom når jeg anbefaler en fast tjekliste i artiklen om ikke bare at tænde Teams som telefonsystem.

3. En gang om året: fuld gennemgang og dokumentation

Her går du mere struktureret til den:

• genbesøger alle scenarier (kontor, hjemme, mobil, reception, køer)
• opdaterer dokumentation og kontaktoplysninger til leverandører
• tjekker, om lovgivning eller branchekrav har ændret sig

Hvis I alligevel arbejder med NIS2 eller lignende, kan nødopkald passende nævnes som en del af jeres samlede beredskab på teleområdet, side om side med de ting jeg er inde på i artiklen om NIS2 og virksomhedsmobiler.

Hvad der mindst skal stå i jeres telefoni-runbook om Teams Phone nødopkald

Hvis en auditor, en ny IT-ansvarlig eller bare din fremtidige dig selv åbner jeres dokumentation, skal de kunne se, at I har tænkt jer om.

Jeg ville som minimum have følgende kapitler i jeres runbook eller interne wiki:

1. Overblik og principper

• Hvilke teknologier bruger I? (Teams Phone med Calling Plan / Direct Routing / blandet)
• Hovedprincip: Hvilken vej går nødopkald fra pc? Fra mobil?
• Hvilke lande / lokationer er omfattet?

2. Lokationer og adresser

• Liste over alle registrerede emergency addresses
• Beskrivelse af hvordan de er mappet til netværk / brugere
• Ejerskab: Hvem må ændre dem, og hvor kommer data fra?

3. Roller og ansvar

• Hvem er ejer, datakilde og tekniker i jeres setup?
• Hvem kontaktes ved fejl på nødopkald (internt og hos leverandør)?
• Hvordan escalering foregår, hvis et testkald fejler?

4. Testprocedurer

• Hvilke tests gennemføres (de 6 scenarier ovenfor eller jeres egne variationer)
• Hyppighed: Hvad testes ved go-live, ved større ændringer og årligt?
• Hvordan aftales 112-tests med operatør / myndigheder?

5. Drift og ændringsstyring

• Hvad udløser en revurdering? (flytning, nyt netværk, ny operatør, nye lande)
• Hvordan sikres opdatering af Teams-konfiguration ved kontorflyt?
• Hvordan dokumenteres ændringer (ændringslog, versionsstyring)?

6. Brugervejledning i øjenhøjde

Og så den del, mange glemmer: Den korte, forståelige vejledning til medarbejderne.

Det kan være et enkelt A4 på intranettet, hvor der står noget i stil med:

• “På kontoret: Ring 112 direkte fra Teams-appen” eller hvad jeres design er
• “Hjemme: Brug altid din normale telefonapp til 112”
• “På mobil: Tryk på telefon-ikonet, ikke Teams-ikonet, ved nødopkald”
• Kontaktinfo, hvis de oplever fejl eller usikkerhed

Hvis du ikke kan forklare det på den måde, så er designet for kompliceret til hverdagen.

7 ting du kan gøre i denne uge for at få styr på Teams Phone nødopkald

Lad os lige samle det, så du faktisk kan gøre noget her og nu, uden at skulle lave et 40-siders projekt.

1. Skriv på én side, hvordan du tror, nødopkald fungerer hos jer i dag (pc, mobil, kontor, hjemme).
2. Book 30 minutter med jeres operatør eller leverandør og få be- eller afkræftet det.
3. Identificer jeres adresser og lokationer: Hovedkontor, evt. lager, andre sites.
4. Udpeg de tre roller: ejer, datakilde, tekniker. Skriv navn og kontaktinfo.
5. Planlæg de 6 tests (eller så mange som er realistiske med jeres setup).
6. Lav en kort brugervejledning til medarbejderne om, hvordan de ringer 112.
7. Læg det hele ind i jeres generelle runbook for telefoni, så det ikke kun findes i din hukommelse.

Teams Phone nødopkald er ikke raketvidenskab. Men det er et af de områder, hvor “vi antager bare” er en virkelig dårlig strategi. Om et par år tror jeg, det vil være lige så naturligt at spørge sin leverandør til nødopkaldsdesign, som det er at spørge til pris og funktioner i dag.