Fra hendelse til betalt levering: slik bygger du flyt mellom ticket, CRM, PSA og ERP
De fleste som leverer profesjonelle IT-tjenester kjenner spennet: Kunden forventer rask og smidig hjelp, mens du må sikre fakturagrad, margin og styrbar drift. Når det blir travelt, oppstår den klassiske konflikten:
- Enten leverer du “god service” som blir ubetalt og ustrukturert
- Eller du strammer inn så mye at kundeservice oppleves som friksjon
Løsningen ligger sjelden i “flere regler” eller “flere felter”. Den ligger i en sammenhengende flyt der hendelser blir til ticket, ticket gjør oppslag mot kundekort (CRM) for å avgjøre betingelser, og leveransen blir håndtert på en måte som både kunden og økonomien tåler.
Hvorfor ticket alene ikke er nok
Et ticketsystem som ikke er tett koblet til kundedata blir i praksis et registreringsskjema. Da må folk “huske” hva som gjelder for kunden, og dere ender med:
- Ulik praksis fra medarbeider til medarbeider
- Diskusjoner om hva som var inkludert / avtalt
- Etterarbeid i faktura og rapportering
- Lavere trivsel fordi trivielt arbeid vokser
Ticketen må være navet, men den må få beslutningsgrunnlaget sitt fra CRM/avtaleverk.
CRM/kundekortet: sannheten om hva kunden har krav på
Når en hendelse blir til en ticket, bør systemet automatisk hente det som avgjør hvordan dere skal levere:
Minstekrav til oppslag mot kundekort:
- Hvilken avtale kunden er på (SLA/respons, åpningstider, eskalering)
- Hvilke tjenester kunden abonnerer på (entitlements)
- Om saken er dekket, delvis dekket eller utenfor avtale
- Timepriser/tillegg (after-hours, utrykning, spesialist)
- Kontaktplan: hvem informeres, hvordan og når
Når dette er maskinlesbart, oppleves kundeservice som profesjonelt: dere trenger ikke å "spørre dere frem" til hva som gjelder.
Tre typer tid - og hvorfor du må skille dem
I praksis består tiden deres av tre kategorier:
- Fakturerbar tid - skal faktureres
- Inkludert tid - dekket av abonnement/pakke
- Ikke-fakturert tid - goodwill, opplæring, småfix, "vi tar den"
Kategori 3 kan være klokt og riktig. Men hvis den er ubevisst, blir den en stille marginlekkasje. Da får du dårlig styring og urettferdighet: noen kunder får mye "ekstra", andre lite - og ingen vet hva det koster.
Bærekraftig kundeservice krever at goodwill-tid er:
- Definert (hva regnes som goodwill?)
- Styrt (hvem kan gi den, hvor mye, når?)
- Målt (per kunde/tjeneste/periode)
Poenget er ikke å fjerne goodwill. Poenget er å finansiere den.
God kundeservice og høy fakturagrad er ikke motsetninger
Det er fullt mulig å levere smidig og raus service - og samtidig ha kontroll på økonomien - hvis dere designer flyten slik at beslutningene tas tidlig i prosessen, ikke i fakturaen.
Praktisk tommelfingerregel:
- Avklar betingelser i det ticketen opprettes eller triageres
- La systemet foreslå faktureringslogikk basert på avtale/entitlement
- Gjør avvik synlige tidlig ("dette er utenfor avtale")
- Bruk "goodwill" som et bevisst valg, ikke en tilfeldighet
Da slipper dere at hele lønnsomheten avgjøres av hvem som husket å føre timer riktig i etterkant.
Automatisering: minst 30% mindre trivielt arbeig (uten å miste kontroll)
Målet med automatisering er ikke å "spare folk vekk". Målet er å fjerne klikkarbeid, øke kvalitet og frigjøre kapasitet til det som faktisk krever vurdering.
Typiske kandidater som gir reel effekt:
- Automatisk opprettelse av ticket fra overvåkning/alarmer
- Auto-kategorisering og routing basert på kunde + tjeneste
- Auto-oppslag mot entitlement/SLA og forslag til prioritet
- Standardiserte kundemeldinger (mottatt, under arbeid, løst)
- Forslag til kunnskapsartikler basert på mønster
- Automatiserte sjekklister for repeterende leveranser (onboarding, endringer)
Viktig kontrollpunkt: Alt som automatiseres må kunne forklares i ettertid: hvorfor ble den routet dit, hvorfor ble den ikke fakturert, hva var grunnlaget? Automatisering uten sporbarhet skaper bare nye konflikter.
Når ticket/PSA kobles til ERP: det handler like mye om data tilbake som faktura ut
Integrason mot ERP/faktura/regnskap blir ofte redusert til "send faktura". Det er nødvendig, men ikke nok. Den store gevinsten er å få tilbake data som gjør drift og økonomi styrbart:
- Betaling/kreditering og avvik
- Inntekter og kostnader per kunde
- Margin per avtale (ikke bare omsetning)
- Grunnlag for prognoser og budsjetter
- Kapasitetsstyring: etterspørsel vs. leveranseevne
Uten denne "loop-en" ender rapporter ofte som aktivitetsoversikter - ikke beslutningsstøtte.
Minimumskrav for å få en flyt som tåler hverdagen
Hvis dere vil bygge dette uten å lage et monster, start med fundamentet:
- Én kundesannhet (ID og struktur)
- Samme kunde må være gjenkjennelig i ticket/PSA, CRM og ERP. Ellers blir alt annet unøyaktig
- Tjenestekatalog som henger sammen med avtale
- Hvis "hva dere leverer" er utydelig, kan dere heller ikke måle eller automatisere.
- Entitlements som er maskinlesbare
- Hvis alt ligger i et PDF-vedlegg eller i hodet på en senior, blir det ikke styrbart.
- Klare regler for ikke-fakturert tid (goodwill)
- Definer rammer og mål det. Ellers vil det vokse.
- Rapportering designes før implementering - ikke etterpå
- Bestem hvilke beslutninger rapportene skal støtte, og bygg datagrunnlaget deretter.
Et nav i flyten: PSA som binder sammen prosess, mennesker og økonomi
For å få dette til i praksis trenger dere et PSA/ticket-nav som kan koble hendelse -> ticket -> kundekort -> avtale/abonnement -> leveranse -> faktura/rapportering, uten at det blir manuelt etterarbeid.
I våre leveranser bruker vi ofte HaloPSA som nav i denne kjeden, fordi det gir et godt grunnlag for å bygge en styrbar flyt mellom prosess, mennesker og økonomi. Men poenget er kravene og modellen: Uansett verktøy får dere ikke stabil kundeservice eller bærekraftig margin hvis kundedata, betingelser og leveransemodell ikke er konsekvent strukturert.
KPI-ene som faktisk flytter adferd
Hvis dere bare måler "antall saker" eller "timer ført", får dere lett feil adferd. Et mer styrbart sett:
- Fakturagrad (totalt og per kunde)
- Margin per avtale (abonnementets bærekraft)
- Inkludert tid vs. brukt tid (entitlement-sannhet)
- Goodwill-tid per kunde (bevisst vs. ubevisst)
- SLA-overholdelse vs. kostnad (service med realisme)
- Automatiseringsgrad (andel saker/oppgaver med standard flyt)
Vanlige fallgruver vi ser
- "Vi fikser det i fakturaen" -> blir alltid dyrt
- Entitlements er uklare -> alt blir diskusjon
- For mye tilpasning for tidlig -> systemet blir u-eid
- Automatisering uten sporbarhet -> skaper mistillit
- Rapportering designes sist -> dere må "gjenopprette sannhet" i etterkant
Avslutning: mulig å løse er ikke det samme som smart å løse
Dette handler ikke om å bygge flest integrasjoner. Det handler om å gjøre leveransen bærekraftig: God service som er finansiert, tydelig og repeterbar - og en økonomimodell som tåler den hverdagen dere faktisk står i.
Vil dere få kontroll på flyten fra hendelse til betalt levering, starter vi nesten alltid med et kort forprosjekt: avklare scope, definere servicekatalog/entitlements og etablere målebildet. Da kan vi ta ansvar for leveransen - ikke bare oppgaver.