Klokken er 08.12, og en kunde aflyser sin tid. Senere på formiddagen afsluttes en større ekspedition. Om eftermiddagen indsendes et spørgeskema, hvor et svar kræver hurtig opfølgning.
Det er tre helt almindelige hændelser i en optikerforretning. Men de kan alle starte den samme slags usynlige ekstraarbejde: nogen skal opdage hændelsen, huske hvad næste skridt er, kopiere information til et regneark, give en kollega besked eller oprette en opgave i et andet system.
Det er netop her, webhooks begynder at ændre noget grundlæggende. Ikke fordi webhooks i sig selv er spektakulære – men fordi de giver OptikPartner mulighed for at fortælle andre systemer, at noget er sket, præcis når det sker.

#Fra "nogen skal huske det" til en fast arbejdsgang
Forestil dig, at en aflyst booking automatisk sætter en arbejdsgang i gang:
- Den relevante information sendes til et eksternt workflow.
- Teamet får besked i Microsoft Teams eller Slack.
- Der oprettes eventuelt en opgave om at kontakte kunden.
- Aflysningen registreres til senere analyse.
Ingen skal kopiere oplysninger. Ingen skal huske alle fire trin. Arbejdsgangen starter, fordi selve hændelsen fandt sted.
Det er forskellen på at have data i et system og at lade data sætte arbejdet i bevægelse.
#Hvad er en webhook egentlig?
En webhook kan bedst beskrives som en digital dørklokke.

Når noget bestemt sker i OptikPartner – eksempelvis at en booking aflyses, en ekspedition afsluttes eller en formular indsendes – kan workflowmotoren sende en struktureret besked til en sikker internetadresse.
Beskeden kan eksempelvis fortælle:
- Hvad der er sket
- Hvornår det skete
- Hvilken butik eller lokation det vedrører
- Hvilken booking, ekspedition eller formular hændelsen kommer fra
- Hvilke relevante værdier den næste arbejdsgang må bruge
Det modtagende system bestemmer derefter, hvad der skal ske. Webhooken er altså ikke hele integrationen. Den er det signal, som kan starte den.
#Hvorfor ændrer det så meget?
Traditionelt kræver en integration, at to systemer bygges tæt sammen. System A skal kende system B, og begge løsninger skal være enige om funktioner, data og kommunikation. Det fungerer godt til dybe, faste integrationer – og den type integrationer vil fortsat være vigtige.
Men virkeligheden i butikkerne er forskellig. Én virksomhed arbejder primært i Microsoft 365. En anden bruger Google Workspace. Nogle har allerede automatiseringer i Make eller Zapier. Andre har deres eget datalager, rapporteringssystem eller interne platform.
Med webhooks behøver OptikPartner ikke kende alle fremtidige systemer på forhånd. Hvis en platform kan modtage et sikkert webhook-kald, kan den potentielt blive en del af arbejdsgangen.
Det gør ikke OptikPartner "integreret med alt". Det giver derimod et åbent fundament, hvor langt flere integrationer kan konfigureres uden at skulle bygge hver eneste arbejdsgang direkte ind i OptikPartner.
#Platforme, der kan bygge videre på signalet

Flere store automatiseringsplatforme er skabt til netop denne måde at arbejde på.
Make kan modtage webhooks som øjeblikkelige startpunkter for såkaldte scenarios. Herfra kan information behandles, filtreres og sendes videre til andre tjenester.
Zapier tilbyder tilsvarende "Catch Hook"-triggere, hvor et webhook kan starte et Zap-workflow.
Microsoft Power Automate kan starte flows, når en HTTP-anmodning modtages. Det er særligt interessant for virksomheder, som allerede arbejder med Microsoft 365, Teams, Excel, SharePoint eller Planner.
Både Microsoft Teams og Slack understøtter desuden webhook-baserede beskeder.
I praksis vil Make, Zapier eller Power Automate ofte fungere som forbindelsesleddet, der modtager hændelsen fra OptikPartner og omsætter den til den besked eller handling, virksomheden ønsker.
Det betyder, at én hændelse i OptikPartner eksempelvis kan blive til:
- En besked i Teams eller Slack
- En række i Excel eller Google Sheets
- En opgave i Planner, Trello eller Asana
- Et input til rapportering eller Business Intelligence
- En handling i et CRM- eller marketingsystem
- Et kald til virksomhedens egen platform
De konkrete muligheder afhænger naturligvis af den valgte platform, dens forbindelser, abonnement og den opsætning, virksomheden har.
#Brugssituation 1: Når en booking bliver aflyst
En aflyst booking er ikke bare en ændring i kalenderen. Måske skal kunden kontaktes. Måske vil butikken forsøge at udfylde den ledige tid. Måske ønsker ledelsen at forstå, hvor ofte aflysninger sker med kort varsel.
Et workflow kunne se sådan ud:
En booking aflyses i OptikPartner → webhooken starter et flow → aflysningen vurderes → teamet får besked → der oprettes en opfølgningsopgave.
Hvis aflysningen sker flere uger før tiden, er en besked måske ikke nødvendig. Sker den derimod en time før en synsprøve, kan workflowet reagere anderledes.
Det interessante er ikke bare, at en besked kan sendes. Det interessante er, at handlingen kan afhænge af situationen.
#Brugssituation 2: Når en ekspedition afsluttes
Når en ekspedition afsluttes, kan den være relevant for mere end kassen. Måske ønsker virksomheden at:
- Opdatere et eksternt ledelsesoverblik
- Registrere bestemte ekspeditioner i et analyseflow
- Starte en intern kvalitetskontrol
- Give marketingplatformen et relevant og begrænset signal
- Sende udvalgte data til virksomhedens eget datalager
Webhooken kan sende hændelsen til Make, Zapier, Power Automate eller en virksomhedsejet løsning. Her kan den behandles og sendes videre til eksempelvis Excel, Google Sheets eller et rapporteringsværktøj.
Det betyder ikke, at alle ekspeditioner skal sendes alle steder. Tværtimod er en god automatisering ofte meget selektiv. Målet er ikke at flytte mest mulig data, men at sende den rigtige information til det rigtige sted på det rigtige tidspunkt.
#Brugssituation 3: Når et formularsvar kræver opfølgning
OptikPartners formularer kan indgå i workflows, når en besvarelse gennemføres, eller når et svar udløser et vigtigt fund. Læs mere om formularerne selv i artiklen Byg jeres egen kundeoplevelse – Forms forbinder nye apps med OptikPartner og se et konkret eksempel i Når kundens svar sætter noget i gang – Forms & Workflows i praksis.
Forestil dig en kundetilfredshedsformular. De fleste svar kræver måske ingen særlig handling. Men hvis en kunde angiver en dårlig oplevelse eller behov for kontakt, kan workflowet reagere:
Formularen registrerer et vigtigt fund → webhooken starter et eksternt flow → den ansvarlige får besked → en opfølgningsopgave oprettes.
Det kan også være en intern kontrolformular, et samtykkeforløb eller en anden struktureret proces. Pointen er, at formularen ikke behøver ende som information, nogen senere skal finde. Den kan blive begyndelsen på næste handling.
#Når det eksterne system kan svare tilbage

En webhook behøver ikke kun være en envejsbesked. I mere avancerede opsætninger kan det eksterne system returnere et struktureret svar. OptikPartners workflow kan derefter bruge svaret som en betingelse for det næste trin.
Et eksternt system kan eksempelvis returnere:
- En prioritet
- En godkendelse
- En kategori
- En score
- Et ja eller nej til, om en bestemt handling skal fortsætte
Workflowet kan herefter vælge forskellige veje. Et formularfund med høj prioritet kan føre til en akut opgave, mens en lavere prioritet kan placeres i en almindelig opfølgningsliste. Et eksternt system kan vurdere informationen, hvorefter OptikPartner fortsætter ud fra resultatet.
Det er her, workflowmotoren bevæger sig fra blot at sende notifikationer til at kunne indgå i egentlige processer på tværs af systemer.
#Fleksibilitet kræver også ansvar
Webhooks skal ikke bruges til ukritisk at sende alle tilgængelige kundeoplysninger videre. En god integration starter med nogle enkle spørgsmål:
- Hvilke oplysninger er faktisk nødvendige?
- Hvem skal modtage dem?
- Hvor bliver de opbevaret?
- Hvilken databehandleraftale og hvilket sikkerhedsniveau tilbyder den eksterne platform?
- Hvad skal der ske, hvis modtageren midlertidigt er utilgængelig?
I OptikPartner har vi derfor arbejdet med blandt andet signerede kald, kontrollerede modtageradresser, genforsøg ved relevante midlertidige fejl og historik over workflowets udførelse.
Det gør fundamentet mere robust, men fjerner ikke behovet for en gennemtænkt opsætning. Eksterne platforme har deres egne priser, begrænsninger, sikkerhedsmodeller og abonnementsvilkår. Webhooks åbner døren – den konkrete arbejdsgang skal stadig designes ordentligt.
#Ikke en erstatning for mennesker – eller for alle integrationer
Målet er ikke at automatisere enhver beslutning i en optikerforretning. Nogle opgaver kræver faglig vurdering. Andre kræver personlig kontakt. Og dybe integrationer til eksempelvis økonomi, betaling eller leverandører kan fortsat have behov for mere specialiserede forbindelser.
Webhooks er stærkest, når de fjerner de små manuelle overgange:
"Når dette sker, skal nogen huske at gøre det næste."
Det frigør ikke medarbejderen fra ansvaret. Det hjælper medarbejderen med at bruge tiden dér, hvor menneskelig vurdering og kundekontakt har værdi.
#Et fundament for arbejdsgange, vi endnu ikke kender
Det mest interessante ved webhooks er måske ikke de integrationer, vi kan beskrive i dag. Det er dem, en butik får brug for om to eller fem år.
Nye kommunikationsværktøjer, analyseplatforme og branchesystemer vil komme til. Virksomheder vil stille nye krav til rapportering og sammenhæng mellem deres systemer. Ved at give workflowmotoren mulighed for at kommunikere gennem åbne, velkendte standarder bliver OptikPartner mindre afhængig af, at alle fremtidige behov allerede er bygget ind i platformen.
Det er vores forståelse af en fremtidssikret platform: ikke et system, der påstår at kunne forudsige alt – men et system, der er bygget til at kunne forbindes med det næste.
#Hvilken manuel overgang ville du fjerne først?
Tænk på en arbejdsgang i jeres butik, som i dag begynder med, at nogen:
- Kopierer information fra ét system til et andet
- Skriver den samme besked igen
- Opdaterer et regneark
- Opretter en opgave manuelt
- Husker at give en kollega besked
Det er ofte her, den mest værdifulde automatisering begynder.
Har I en arbejdsgang, som kunne blive mere sikker, hurtigere eller lettere med OptikPartners workflowmotor og webhooks, tager vi gerne en konkret dialog om mulighederne – og om hvor en automatisering faktisk giver mening.



