Gå til indhold

Case: software til teleselskaber og fiberselskaber

Software til teleselskaber i praksis: dækningstjek, bestillingsflow og integrationer bygget for fiber- og teleselskaber, og hvornår en freelancer passer.

Af

Freelance full-stack udvikler

Udgivet
Læsetid
8 min.
Indhold i indlægget7

Software til teleselskaber skal først og fremmest få én ting til at virke: at en kunde kan slå sin adresse op, se hvad der kan leveres, og bestille uden at nogen skal rette ordren bagefter. Jeg har arbejdet som udvikler på projekter for fire virksomheder i fiber- og telebranchen: Onefiber, GlobalConnect, Hiper og Fiber Teamet. Her samler jeg hvad opgaverne gik ud på, hvad der var svært, og hvornår en freelancer som mig passer til den slags arbejde.

[PLACEHOLDER: Bekræft hvilke af de fire virksomheder der må nævnes med navn, og fjern resten fra intro, tabel og afsnit.]

[PLACEHOLDER: 1-2 sætninger om din rolle på tværs af projekterne, fx freelancer i kundens eget team, underleverandør til et bureau eller direkte aftale, og cirka hvornår.]

Den korte version

I telebranchen bygger man sjældent på bar mark. Der findes næsten altid systemer til kunder, produkter, ordrer og fakturering i forvejen, og det nye skal tale med dem. Sådan fordelte opgaverne sig:

VirksomhedOpgaveMin rolleTeknologi
Onefiber[PLACEHOLDER: opgave][PLACEHOLDER: rolle][PLACEHOLDER: stack]
GlobalConnect[PLACEHOLDER: opgave][PLACEHOLDER: rolle][PLACEHOLDER: stack]
Hiper[PLACEHOLDER: opgave][PLACEHOLDER: rolle][PLACEHOLDER: stack]
Fiber Teamet[PLACEHOLDER: opgave][PLACEHOLDER: rolle][PLACEHOLDER: stack]

I projekterne her har jeg arbejdet i kundernes forretning og på deres præmisser. Fokus er på integrationer, data og løsninger, der passer ind i eksisterende systemer.

Hvad fiber- og teleselskaber typisk skal bruge på nettet

Selskaberne er forskellige. Nogle ejer selve fibernettet, andre sælger internet, tv og telefoni på net som andre ejer. Men på nettet går de samme fem behov igen:

  1. Dækningstjek på adresse: kunden skriver sin adresse og får at vide om der kan leveres fiber, hvilke hastigheder der er mulige, og hvornår. Det er typisk det første en ny kunde gør.
  2. Bestillingsflow: produktvalg, startdato, kontaktoplysninger, samtykker og eventuelt udstyr. Bag fire enkle trin ligger ofte mange regler om binding, kampagnepriser og hvad der kan leveres på netop den adresse.
  3. Interessetilmelding og kampagnesider: når et nyt område skal have fiber, vil selskabet ofte vide om nok husstande er interesserede, før der graves. Det kræver tilmelding pr. adresse og et overblik over hvor tæt hvert område er på målet.
  4. Selvbetjening: ordrestatus, installationsdato, flytning og opsigelse. Hver ting kunden selv kan klare, er en henvendelse mindre til kundeservice.
  5. Integrationer: ordren skal videre til CRM, fakturering og de systemer der bestiller installation eller aktiverer forbindelsen.

Hvor meget der skal udvikles fra bunden, afhænger af selskabets størrelse. Store selskaber har typisk standardsystemer i bunden og bruger udviklere til det kunden ser, og til forbindelserne mellem systemerne. Mindre selskaber har oftere brug for hele kæden.

Selvbetjening er i praksis en kundeportal. Er det dér du står, har jeg skrevet om hvad en kundeportal typisk koster at få udviklet.

Projekterne

Her er de enkelte projekter. Jeg beskriver kun det kunderne har godkendt, og tal står kun hvor de er ægte og må deles.

Onefiber

[PLACEHOLDER: Udgangspunkt. Hvad var behovet, og hvordan kom du ind i projektet?]

[PLACEHOLDER: Opgaven. Hvad byggede du konkret (fx dækningstjek, bestillingsflow, kampagneside eller integration), og med hvilken stack?]

[PLACEHOLDER: Resultat. Kun tal, udsagn og citater som kunden har godkendt.]

GlobalConnect

[PLACEHOLDER: Udgangspunkt. Hvad var behovet, og hvordan kom du ind i projektet?]

[PLACEHOLDER: Opgaven. Hvad byggede du konkret, og med hvilken stack?]

[PLACEHOLDER: Resultat. Kun tal, udsagn og citater som kunden har godkendt.]

Hiper

[PLACEHOLDER: Udgangspunkt. Hvad var behovet, og hvordan kom du ind i projektet?]

[PLACEHOLDER: Opgaven. Hvad byggede du konkret, og med hvilken stack?]

[PLACEHOLDER: Resultat. Kun tal, udsagn og citater som kunden har godkendt.]

Fiber Teamet

[PLACEHOLDER: Udgangspunkt. Hvad var behovet, og hvordan kom du ind i projektet?]

[PLACEHOLDER: Opgaven. Hvad byggede du konkret, og med hvilken stack?]

[PLACEHOLDER: Resultat. Kun tal, udsagn og citater som kunden har godkendt.]

Hvornår en freelancer passer til teleopgaver, og hvornår ikke

Et teleselskab har typisk både et internt it-team og faste leverandører. En freelancer erstatter ikke nogen af dem. Jeg er et supplement, når der er en konkret opgave der skal løses, og teamet ikke har tid til den.

En freelancer passer godt til:

  • En afgrænset leverance: et nyt dækningstjek, et bestillingsflow, en kampagneside med interessetilmelding eller en integration mellem to systemer.
  • Ekstra kapacitet i et eksisterende udviklingsteam, hvor jeg arbejder i jeres kodebase og efter jeres processer for kodegennemgang og udgivelse.
  • Et mindre selskab der vil have én udvikler med overblik over hele webløsningen og direkte kontakt til den der skriver koden.

En freelancer passer ikke til:

  • Kernesystemer til provisionering (aktivering af forbindelser) og netdrift. Det kræver et team, specialiseret telesoftware og folk der kender netværket indefra.
  • Døgnvagt med garanteret svartid om natten. Jeg svarer på henvendelser inden for én hverdag, men det er ikke en vagtordning, og det kan én person ikke love ærligt.
  • Store udbud med krav om certificeringer og mange konsulenter bag tilbuddet. Her er et bureau eller et konsulenthus det rigtige svar.

Ved større opgaver starter jeg med et betalt forprojekt til fast pris, så omfang, integrationer og pris er på plads, før der skrives kode. Du ejer koden fra første dag. Hele forløbet har jeg beskrevet i gennemgangen af hvordan et projekt med mig foregår fra første opkald til lancering.

Fire ting der går igen i teleprojekter

Punkterne her gælder for de fleste webløsninger i branchen, og det er dem jeg kigger efter først, når jeg ser på en ny opgave.

Adressen skal komme fra en liste

Den samme adresse kan skrives på mange måder: "2. tv.", "2 tv", "st." eller med og uden bogstav i husnummeret. Lader du kunden skrive frit, ender ordren med en adresse som ingen af de andre systemer kan matche. Min tommelfingerregel er at kunden altid vælger fra en liste over officielle adresser, i Danmark fra Danmarks Adresseregister, og at systemet gemmer adressens id og ikke kun teksten.

Kampagner giver trafikspidser

Når en kampagne sendes ud til et helt område, kommer mange besøgende på samme tid, og alle vil slå deres adresse op. Dækningstjekket skal derfor svare hurtigt og kunne gemme svar midlertidigt (cache). Bestillinger bør lægges i en kø og behandles i baggrunden, så en langsom ekstern tjeneste ikke får hele siden til at hænge.

En ordre må ikke forsvinde

En ordre på et abonnement er penge. Fejler kaldet til fakturering eller aktivering, skal ordren være gemt, fejlen logget, og systemet skal prøve igen og give nogen besked. Min anbefaling er at hver ordre kan følges fra formularen til det sidste system, så kundeservice kan svare på "hvor er min ordre?" uden at spørge en udvikler.

Tilgængelighed er et lovkrav

Ifølge EU's tilgængelighedsdirektiv skal elektroniske kommunikationstjenester og e-handel, der leveres til forbrugere efter 28. juni 2025, leve op til tilgængelighedskrav. Mikrovirksomheder med under 10 ansatte og en årsomsætning eller balance på højst 2 mio. euro er undtaget for tjenester. For et teleselskab betyder det i praksis at dækningstjek og bestillingsflow skal kunne bruges med tastatur og skærmlæser. Den konkrete forpligtelse bør du få afklaret med en jurist.

[PLACEHOLDER: Hvilket af de fire punkter fyldte mest i dine projekter? Et konkret eksempel på et problem og hvordan det blev løst, kun med detaljer kunden har godkendt.]

Næste skridt

Står dit selskab med en lignende opgave, så start med tre oplysninger: hvad løsningen skal kunne, hvilke systemer den skal tale med, og om der er en fast dato, fx en kampagnestart. Med dem kan jeg som regel hurtigt sige om opgaven passer til mig, og hvad det næste skridt er.

Du kan læse mere om hvordan jeg udvikler webapps og platforme til virksomheder. Vil du se flere projekter, har jeg også skrevet om nye funktioner til en medarbejderplatform i vækst og digitale løsninger til en fitnesskæde.

Ofte stillede spørgsmål

Kan du arbejde i vores eksisterende kodebase og systemer?

Ja, det er en helt almindelig opgave for en freelancer. Jeg starter med at læse koden og få adgang til et testmiljø, og jeg følger jeres processer for kodegennemgang og udgivelse. Er koden i en stand hvor det er risikabelt at bygge videre, siger jeg det, før jeg går i gang, og foreslår en afgrænset oprydning først.

Hvordan håndterer du fortrolighed og kundedata?

Jeg skriver gerne under på en fortrolighedsaftale, og får jeg adgang til personoplysninger, skal der som regel også være en databehandleraftale efter GDPR. Jeg arbejder helst med testdata i stedet for rigtige kundedata og kun med de adgange opgaven kræver. Spørg din egen jurist, hvis du er i tvivl om hvilke aftaler jeres situation kræver.

Hvor lang tid tager det at bygge et dækningstjek eller et bestillingsflow?

Det afhænger mere af integrationerne end af skærmbillederne. Selve siderne tager sjældent længst tid. Det gør aftaler om dataformater, adgang til testmiljøer i de andre systemer og test af alle produktregler. Derfor starter jeg større opgaver med et forprojekt til fast pris, hvor omfang og tidsplan bliver konkrete, før du binder dig til selve udviklingen.

Hvem ejer koden, når projektet er færdigt?

Det gør du, fra første dag. Koden ligger i jeres eget kodearkiv, så I kan fortsætte med jeres interne team eller en anden leverandør uden at skulle spørge mig. Det er vigtigt i en branche hvor løsningen typisk skal leve i mange år og tilpasses nye produkter og kampagner.