BC SaaS servicekatalog v0.1 og update-runbook

Status: v0.1 — struktur til intern afstemning med SDM, salg og leder
Ejer (design): Jens Hulvej Hinnerup
Ejer (drift, mål): SDM / ServiceDesk, når kataloget er v1
Ikke: Field Service-modulet. Dette er Operate for Business Central online.

9altitudes har allerede Lifecycle Management, ServiceDesk og Customer Success. Dette katalog oversætter det til BC SaaS i Danmark: tre niveauer, en skarp grænse mellem support og projekt, og en update-fabrik bundet til Microsofts waves.

Priser og SLA-tal landes med salg/SDM. Her står hvad der er med, så I ikke sælger helte.

---

To ydelser, der ofte blandes sammen

Microsoft opdaterer platformen. 9altitudes opdaterer kundens hverdag. Det er to jobs.

	Miljøpleje (Operate)	Funktionel support
Job	Hold miljøet sundt gennem waves	Hjælp brugere med at køre forretningen
Eksempler	Sandbox, app-kompatibilitet, telemetry, storage, update-vindue	“Hvordan bogfører jeg?”, dimensioner, træning, små setup-rettelser
Fejler når	Update rammer produktion uforberedt	Tickets bliver til skjult projekttid

Kataloget sælger miljøpleje som abonnement og funktionel support som abonnement. Udvikling og nye processer er projekt.

---

Support vs. projekt

Brug denne grænse i tickets, estimater og QBR. Hvis I er i tvivl, er det et projekt indtil det er afkræftet.

Support (inden for aftalen)

• Fejl i eksisterende proces (“det virkede mandag”)
• How-to på funktioner kunden allerede har
• Rettighed, rum, printer, brugere — inden for aftalt volumen
• Update-fabrikken (sandbox, teknisk tjek, go/no-go)
• Små setup-ændringer under en aftalt tidsgrænse (foreslå 2 timer pr. sag, max 8 timer pr. måned samlet — justér med SDM)
• Telemetry-alarmer: “noget er langsomt / et web service-kald fejler”

Projekt (SOW / T&M / change request)

• Ny forretningsproces eller ny integration
• Ny PTE eller væsentlig ændring af eksisterende PTE
• Data-migration, historik, ny virksomhed
• Træningsforløb ud over What’s new
• Copilot/agent-enablement som program (governance, prompts, roller) — ikke “tænd knappen”
• Must-work-test som 9A kører for kunden ud over tier-loftet
• Alt der ændrer løsningens blueprint

Gråzone-regel: Hvis sagen kræver acceptkriterier, testdata og deploy, er det et projekt. Hvis den kan lukkes med en kendt procedure, er det support.

Sæt feltet type = miljø | funktion | projekt på tickets, så I kan måle lækagen.

---

Tre tiers

Navne kan skifte til 9A-sprog (Lifecycle / Managed Services). Indholdet skal holde.

Fælles for alle tiers: dansk kontakt, ServiceDesk-åbningstid, eskalering til 9A-eksperter, og at kunden har en navngiven superuser.

Basis — “ingen overraskelser på major”

Til kunder med få apps, lidt PTE, og intern IT/superuser der kan teste.

• Major update (2×/år): tidlig varsling, sandbox-kopi, teknisk tjek af Microsoft-apps + aftalte ISV’er + PTE (installeres/opdateres, synkroniserer, miljøet kommer op)
• Kunden kører selv must-work-listen og siger go/no-go
• Ét aftalt produktionsvindue inden for Microsofts update-periode
• Månedlig 1-siders helbred: storage, miljøstatus, kommende update
• Funktionel support: ticket-volumen efter SLA (sæt tal med SDM)
• Ikke: telemetry-døgnvagt, minor-sandbox hver måned, QBR, 9A-kørt proces-test

Plus — “vi ser det før I mærker det”

Til kunder med integrationer, flere apps, eller uden overskud til at jage waves.

Alt i Basis, plus:

• Application Insights slået til; 9A overvåger systemsignaler (performance, failed web services, update-signaler LC0100 m.fl.) — ikke finansposter
• Sandbox også på udvalgte minors, når release notes rammer kundens apps/integrationer
• Storage- og kapacitetsvarsling med anbefalet oprydning
• What’s new 45 min pr. major (kundeformat, dansk)
• Fast update-ugeaftale (fx “anden tirsdag aften i vinduet”), med én ombooking pr. wave
• Kvartalsvis 45 min check-in (let-QBR): helbred + 3 features I ikke bruger

Fuld — “Operate som en funktion”

Til kunder hvor BC er produktionskritisk, eller hvor 9A også er SDM.

Alt i Plus, plus:

• Navngiven Service Delivery-kontakt og månedlig 30 min drift
• QBR 4×/år med telemetry-helbred, feature-adoption, backlog, næste wave — se skabeloner/qbr.md
• 9A faciliterer must-work-test (kunden udfører, 9A styrer listen og go/no-go)
• Hypercare-kit ved nye go-lives: 2–4 uger, daglig stand-up første uge, skriftlige exit-kriterier
• Handoff-checkliste fra projektteam → Operate før go-live
• Ét Copilot/agent-demo-spor pr. år (enablement, ikke et AI-projekt)
• Prioriteret eskalering

Hvad ingen tier indeholder

• Udvikling af ny PTE
• At 9A tester hele forretningen end-to-end uden kundens superuser
• Læsning af kundens forretningsdata under “monitoring”
• Ubegrænset T&M skjult som support
• At Microsofts grace period kan forhandles væk

---

Prislogik (uden kronebeløb)

Fast månedlig pris pr. miljø (produktion). Sandbox til update-fabrikken er inkluderet. Ekstra miljøer prissættes.

Prisen stiger med: antal PTE’er, antal ISV-apps, integrationer, antal selskaber, krav til update-vindue uden for normal tid.

Salg sælger tier + tillæg, ikke “vi passer på jer”. Tillæg-eksempler: ekstra produktion, 24/7-vindue, ekstra sprog, ekstra ISV-pakke.

Første år: land intern kost (timer pr. wave × antal kunder) før officiel prisliste. Pilot på 2–3 kunder i Plus eller Fuld.

---

Roller

Rolle	Ansvar
Kunde-superuser	Must-work-test, go/no-go på forretning, 1st line internt
ServiceDesk	Tickets, triagering miljø / funktion / projekt
Operate-tekniker	Sandbox, app-tjek, telemetry, Admin Center
Evangelist (Jens, 7 t/uge)	Design, runbook, Academy, wave-brief, QBR-skabelon
SDM	Aftale, SLA, QBR på Fuld, eskalering
Projektleder	Handoff ind i Operate, ikke ejer efter exit-kriterier
Salg	Tier-valg, ikke at love projekt ind i support

---

Update-runbook (fabrikken)

Kør den ens hver gang. Major: altid. Minor: efter tier.

Microsoft-signaler: mail til notification recipients + telemetry LC0100 når update er tilgængelig. Admin Center er sandheden, ikke LinkedIn.

0. Stamdata (én gang pr. kunde, opdateres ved QBR)

• Produktion + sandbox-navne
• Notification recipients
• App-liste: Microsoft / ISV / PTE
• Integrationer og batch-vinduer
• Must-work-listen (10 processer)
• Blackout-perioder (lønkørsel, lageroptælling, spidssæson)
• Tier og aftalt update-vindue

1. Signal (dag 0)

• ☐ Update synlig i Admin Center
• ☐ LC0100 / mail registreret
• ☐ Release plan-delta: 5 linjer på dansk “hvad det betyder for denne kunde” (evangelist eller Operate-tekniker)
• ☐ Intern note: rammer det kundens apps, PTE eller integrationer?

2. Sandbox (dag 0–2)

• ☐ Kopiér produktion → update-sandbox (eller opdatér den dedikerede)
• ☐ Anvend target-version i sandbox
• ☐ Bekræft miljøet starter; noter fejl i extension update / data upgrade

3. Teknisk tjek (dag 1–4)

• ☐ Microsoft-apps opdateret
• ☐ ISV-apps: kompatible versioner, eller sag hos ISV
• ☐ PTE: compile/install/sync; kendte breaking changes
• ☐ Ét kald pr. kritisk integration (ikke hele forretningen)
• ☐ Telemetry: ingen rød exception-storm efter sandbox-update
• ☐ Resultat: teknisk GO / NO-GO (NO-GO = reschedule inden for Microsoft-vinduet, eller hotfix-projekt)

4. Forretningstest (dag 3–7)

• ☐ Send must-work-listen + sandbox-link til superuser
• ☐ Basis: kunden tester selv, 9A svarer på fejl
• ☐ Plus/Fuld: 9A booker testvindue og styrer listen
• ☐ Hver proces: OK / fejl / ikke testet
• ☐ Resultat: forretnings-GO / NO-GO

5. Produktion

• ☐ Book vindue (ikke kundens blackout, inden for Microsoft-perioden)
• ☐ Informér: hvad der sker, hvornår, hvem der er vagt
• ☐ Kør update
• ☐ Bekræft version + apps
• ☐ Superuser kører 3 røgtest (subset af must-work)
• ☐ Luk med “grøn” i ticket/log

6. Adoption (inden 10 hverdage efter major)

• ☐ What’s new 45 min (Plus/Fuld; Basis: 1-siders mail)
• ☐ 3 features at prøve; 1 feature at slå fra/styre (fx Copilot)
• ☐ Opdatér stamdata og must-work hvis processer har ændret sig

7. Hvis det går galt

• ☐ Produktion nede / proces nede: eskalér som P1, ikke som “update-spørgsmål”
• ☐ App-fejl: ISV eller PTE-hotfix som projekt hvis det overstiger supportloftet
• ☐ Microsoft-platform: partner support + dokumentation af request-id
• ☐ Læringsnote i runbook-loggen: én linje, så næste wave bliver billigere

Kadence

Begivenhed	Hvornår
Major	april og oktober (wave 1 / wave 2)
Minor	månedligt; Plus/Fuld vurderer sandbox
Grace period	typisk september (efter april-wave) og marts (efter oktober-wave) — her kan I ikke skubbe

Første gang fabrikken køres, er evangelist med på hele løbet. Anden gang sidder Operate-tekniker i stolen. Tredje gang er Jens kun design-owner.

---

Handoff: projekt → Operate

Startes i Implement, øves i UAT, er færdig før hypercare slutter. Uden dette fejler kataloget.

• ☐ Løsningsblueprint og app-liste overleveret
• ☐ Must-work-liste godkendt af kunden
• ☐ Telemetry tændt (Plus/Fuld; anbefalet på Basis)
• ☐ Notification recipients sat
• ☐ Superuser navngivet + backup
• ☐ Ticket-vej og hvad der ikke er support
• ☐ Hypercare: start, daglig stand-up, exit-kriterier (fx: ingen P1 i 5 hverdage, backlog < N, superuser kører must-work uden 9A)
• ☐ Første update-vindue efter go-live er booket
• ☐ SDM har accepteret kunden på et tier

Microsoft-referencer til intern brug: support model, support team, transition checklist, update rollout.

---

Pilot (jan–apr 2027 ifølge roadmap)

2–3 SaaS-kunder, helst én Basis og én Plus/Fuld.

Succes: én major eller to minors kørt på runbooken uden helte-nat; tickets mærket med type; mindst ét QBR eller check-in afholdt; skriftlig feedback fra superuser.

Dump ikke hele DK-porteføljen på v0.1.