Heimstaden – tekniskt mötesunderlag för Vitec och AI-planering

Kärnbudskap

Det säljaren tryggt kan säga redan nu

Förslag på öppning i mötet ”Vi ser en realistisk väg att bygga detta som ett avgränsat planeringslager ovanpå Vitec, utan att skapa ett nytt fastighetssystem. Vitec har officiella integrationsvägar och redan vissa bokningsfunktioner. Vårt fokus blir att göra prioritering, tidsestimering, resursfördelning och omplanering intelligent. Innan vi låser pilot, tidplan och pris behöver vi verifiera exakt API- och dataåtkomst i er miljö.”

Vitec ska inte ersättas

Ärenden, historik och grunddata ligger kvar i Vitec. Vårt lager arbetar mellan inkommet ärende och utförande.

Officiella integrationsvägar finns

Evo API, fastAPI och DBAccess ger flera möjliga vägar. Exakt väg avgörs av Heimstadens produkter, version och licenser.

Vitec har redan självbokning

Det betyder att enkel tidsbokning inte bör säljas som vår innovation. Vårt värde ligger i intelligent slot-generering och optimering.

Den stora frågan är datatillgång

AI och optimering är genomförbart. Den kritiska beslutspunkten är vilka fält och skrivoperationer Heimstadens Vitec-miljö faktiskt exponerar.

Utgångsläge

Vad vi har hört från kunden

~160

fastighetsskötare som berörs av planering, bokning och ombokning.

20–25 %

uppskattad arbetstid som enligt kunden går till administration och bokning.

~25 %

av kontakterna till kundservice uppges gälla status på befintliga ärenden.

2–3 år

möjlig tidshorisont innan ett gemensamt koncernsystem kan förändra förutsättningarna.

Viktigt: siffrorna ovan kommer från kundsamtalet. De ska användas som hypoteser för pilotens baseline – inte som oberoende verifierade fakta.

Frågor och svar 1–5

Vitec, data och integration

Bekräftat Verifiera hos Heimstaden Vår rekommendation

1

Är lösningen tekniskt genomförbar utan att ersätta Vitec?

Ja, principiellt

Ja. Den rimliga arkitekturen är ett separat boknings- och optimeringslager som läser ärenden från Vitec, räknar fram planering och skriver tillbaka det som Vitec tillåter. Vitec fortsätter vara system of record.

Svar att ge kunden

”Vi bygger inte ett nytt fastighetssystem. Vi kopplar ett intelligent planeringslager till ert befintliga Vitec och håller Vitec som master för ärenden och historik.”

Teknisk fördjupning och avgränsning

Vitec beskriver Evo API som ett gemensamt API med CRUD-stöd och möjlighet att hämta förändrad data. Vitec stödjer även fastAPI, där arbetspaket 1 omfattar arbetsorder och felanmälan.

Det som återstår: vilka Vitec-produkter Heimstaden kör, om Evo API/fastAPI är aktiverat och vilka scopes deras tenant ger oss.

S1 S4

2

Kan vi få ut den data som behövs från Vitec?

Troligen – måste testas

Mycket talar för det. Publik dokumentation visar stöd för ärenden/arbetsorder, fastighetsstruktur, hyresgäst- och kontaktinformation, resurs, status och inställelsetid. Men exakt fältmappning och behörighet måste verifieras i Heimstadens miljö.

Svar att ge kunden

”Den datamodell vi behöver finns i eller runt Vitec. Nästa steg är att bekräfta att just er installation exponerar de aktuella fälten via API.”

Vilka fält vi behöver

Ärende-ID, typ, beskrivning, status, prioritet/SLA och skapad tid.
Fastighet, objekt/lägenhet, adress och helst koordinat eller stabil adressnyckel.
Hyresgästens kontaktkanal som får användas för bokning.
Ansvarig resurs, planerad start/slut, faktiskt utfall och eventuell orsak till återbesök.
Kompetens, arbetstid och kalenderblockeringar – om detta finns i Vitec eller annat system.

Inte bekräftat publikt: att alla dessa fält finns i samma API, att kompetens finns strukturerat eller att återbesöksorsak är tillgänglig. Detta är frågor till sandboxen.

S4 S5 S7

3

Hur bör integrationen mot Vitec göras?

Prioriterad väg

Först Evo API, därefter fastAPI och sist DBAccess för läsning. Direkt skrivning i Vitecs databas bör undvikas.

Svar att ge kunden

”Vi börjar med Vitecs officiella API:er. Om ett visst datauttag saknas kan DBAccess vara en läsande reservväg, men alla uppdateringar ska ske genom stödda gränssnitt.”

Varför denna ordning?

Evo API: Vitecs framtida gemensamma API, med CRUD och förändringshämtning.
fastAPI: standardiserade domänobjekt för bland annat felanmälan och arbetsorder.
DBAccess: datauttag genom behovsanpassade databasvyer; lämpligt som fallback för läsning.

Integrationen bör kapslas i en adapter så att resten av lösningen inte känner till Vitec-specifika detaljer.

S1 S3 S4

4

Kan vi skriva tillbaka bokad tid och ansvarig fastighetsskötare?

Målbild – ej lovad ännu

Det är den önskade målbilden, men vi ska inte lova den före ett API-test. Evo API har generellt CRUD-stöd och fastAPI beskriver uppdatering av arbetsorder. Vitecs användargränssnitt har resurs och inställelsetid. Exakta endpoints och rättigheter för Heimstaden är dock inte publikt verifierade.

Svar att ge kunden

”Vi designar piloten för att boka tid och resurs tillbaka till Vitec. Det blir en teknisk beslutspunkt i förstudien: vi bekräftar operationen i er testmiljö innan vi lovar produktionsflödet.”

Acceptanskriterium för integrationsprovet

Läs ett testärende med stabilt Vitec-ID.
Uppdatera planerad start/slut eller motsvarande bokningsfält.
Uppdatera ansvarig resurs – om modellen tillåter det.
Läs tillbaka ändringen och verifiera att Vitecs normala arbetsflöde inte bryts.
Testa idempotens, behörighet, loggning och felhantering.

S1 S5 S7

5

Kan lösningen reagera på nya och ändrade ärenden nära realtid?

Förändringshämtning ja; webhook oklart

Ja, på minst en praktisk nivå. Evo API uppges kunna hämta endast förändrad data. Vi har däremot inte hittat publik bekräftelse på webhook/eventström för just Heimstadens Vitec-flöde.

Svar att ge kunden

”Vi kan bygga inkrementell synk. Om Vitec erbjuder events i er miljö använder vi dem; annars hämtar vi förändringar med ett kontrollerat intervall.”

Teknisk strategi

Prioritetsordningen är: 1) webhook/event, 2) delta/change-synk, 3) polling med cursor eller ändringstid. Frekvensen sätts efter SLA, rate limits och kostnadsmodell.

Fråga till Vitec/Heimstaden: finns events, webhook, ändringscursor, rate limits och garanterad ordning på förändringar?

S1 S2

Frågor och svar 6–10

Bokning, kalender och intelligent planering

6

Har Vitec redan självbokning för hyresgäster?

Ja

Ja. Vitecs dokumentation från juni 2026 beskriver självbokning och ombokning i Arena för bokningsbara ärenden. Tider hämtas från resursernas Outlook-kalendrar och hyresgäst samt resurs notifieras vid om- eller avbokning.

Svar att ge kunden

”Vi vill först förstå hur mycket av självbokningen ni redan använder i Vitec. Vi ska inte bygga om något som redan fungerar – vi ska göra urvalet av tider och resursplaneringen smartare.”

Var vår differentiering börjar

Vitecs beskrivna självbokning bygger på bokningsbara kalenderblock och kan slumpa resurs när flera är lediga samtidigt. Vårt planerade mervärde är att räkna fram vilka tider som bör erbjudas utifrån prioritet, duration, resväg, kompetens och hela dagens belastning.

Fråga till Heimstaden: använder ni Arena-självbokning idag, i vilken omfattning och för vilka ärendetyper?

S6

7

Kan kundservice se tider och boka åt hyresgästen?

Ja, som del av vårt lager

Ja, när vi har tillgång till samma tillgänglighet och bokningsoperation. Kundservice kan få en enkel vy med rekommenderade tider och boka i samma flöde som hyresgästen.

Svar att ge kunden

”Självservice och kundservice använder samma motor. Hyresgästen kan välja själv, eller så kan kundservice boka en rekommenderad tid under samtalet.”

Funktioner i en första kundservicevy

Sök på ärende, adress, lägenhet eller kontakt.
Visa 3–5 rekommenderade tider och varför de är lämpliga.
Boka, omboka och avboka med tydlig audit trail.
Visa status och senaste kommunikation utan att skapa parallell ärendehistorik.

Beroende: autentisering/SSO, rollstyrning och en bekräftad skrivväg till Vitec eller dess bokningskomponent.

8

Hur ska ”AI:n” prioritera och uppskatta arbetstid?

Hybrid – inte en ensam LLM

Med tre lager: fasta verksamhetsregler för säkerhet och SLA, språkmodell för att tolka fritext samt statistisk modell för tidsestimat. Osäkra eller riskfyllda fall går till mänsklig kontroll.

Svar att ge kunden

”Akuta regler och SLA styrs deterministiskt. AI hjälper oss att förstå fritext, föreslå kategori och uppskatta tidsåtgång – men den får inte ensam bestämma över säkerhetskritiska regler.”

Exempel på beslutskedja

Texten klassificeras: exempelvis VVS, vattenrisk, badrum.
Regelmotorn kontrollerar akuta signaler och kundens SLA.
Duration estimeras från ärendetyp, fastighet och historiskt utfall.
En confidence score avgör om systemet kan gå vidare eller be om mänskligt beslut/följdfråga.

Modellresultat och mänskliga korrigeringar sparas för uppföljning, inte som ny masterdata för ärendet.

9

Hur optimeras fastighetsskötarnas arbetsdag?

Constraint- och ruttoptimering

Själva schemat bör lösas matematiskt, inte av en språkmodell. Optimeraren väger samman prioritet, tidsfönster, arbetstid, restid, kompetens, raster och befintliga bokningar.

Svar att ge kunden

”AI:n förstår ärendet, men en optimeringsmotor bygger dagen. Det gör resultatet reproducerbart, mätbart och möjligt att styra med era regler.”

Teknisk modell

Problemet liknar Vehicle Routing with Time Windows kombinerat med personal- och kompetensbegränsningar. OR-Tools är ett möjligt verktyg, men slutligt val görs efter en prototyp med Heimstadens verkliga volymer och constraints.

Hårda constraints: SLA, kompetens, arbetstid, låsta bokningar, behörigheter.
Mjuka mål: minimera resa, väntetid, övertid och ombokningar; maximera produktiv tid och stabilitet.
Resultatet behöver inte vara teoretiskt optimalt – det ska vara snabbt, genomförbart och bättre än nuläget.

S11

10

Kan ett akut ärende automatiskt förändra dagens plan?

Ja, stegvis autonomi

Ja. Ett akut ärende kan trigga omoptimering, men systemet ska följa tydliga låsregler och kommunikationsregler. I piloten bör omplaneringen först föreslås för godkännande innan full automation aktiveras.

Svar att ge kunden

”Vid exempelvis en vattenläcka kan systemet hitta närmaste lämpliga resurs, skydda pågående jobb, flytta de minst kritiska besöken och meddela berörda hyresgäster.”

Skyddsräcken för omplanering

Pågående jobb och jobb som startar inom ett valt låsfönster flyttas normalt inte.
Endast jobb som verksamheten har markerat som ombokningsbara får flyttas.
Varje ändring loggas med orsak, gammal plan och ny plan.
Hyresgästen får en begriplig notifiering och en ny bokningsmöjlighet.
Operatören kan alltid stoppa eller återställa omplaneringen.

Målarkitektur

Bygg värdet ovanpå – inte bredvid – Vitec

VitecÄrenden, fastigheter, objekt, historik och slutlig dokumentation

IntegrationsadapterSynk, datakontrakt, idempotens, behörighet och skrivning tillbaka

PlaneringslagretKlassificering, duration, optimering, booking API, kommunikation och KPI

Kalendern: Microsoft 365/Outlook kan vara källa för personlig tillgänglighet, medan Vitec förblir master för arbetsordern. Exakt ansvarsfördelning behöver beslutas så att vi undviker två konkurrerande kalendermasters.

S6 S12 S13

Frågor och svar 11–14

Uppföljning, säkerhet och framtidssäkring

11

Kan vi mäta om piloten faktiskt skapar värde?

Ja – baseline krävs

Ja. Vitec har redan stöd för statistik över bland annat antal, tid och kostnad samt rapportering av tid på åtgärder. Vårt lager kan komplettera med boknings- och planeringsmått.

Svar att ge kunden

”Vi sätter baseline före piloten och mäter de två affärsmål ni själva har pekat ut: färre statuskontakter och mer produktiv tid – plus kvaliteten i planeringen.”

Föreslagna pilot-KPI:er

Andel statuskontakter till kundservice per 100 öppna ärenden.
Administrativ tid per ärende och per fastighetsskötare.
Tid från skapat ärende till erbjuden respektive bokad tid.
Planerad kontra faktisk duration, restid och outnyttjad tid.
Ombokningar, återbesök, no-show och andel automatiskt bokade ärenden.
Produktiva ärenden per resurs/dag och hyresgästnöjdhet efter besök.

Viktigt: kundens 20–25 % och 25 % används som hypoteser tills en mätbar baseline finns.

S9 S10

12

Hur hanteras GDPR, säkerhet och hyresgästdata?

Privacy by design

Genom dataminimering och tydlig ansvarsfördelning. Planeringslagret ska bara behandla den information som krävs för bokning och utförande, med kryptering, rollstyrning, loggning, gallring och personuppgiftsbiträdesavtal.

Svar att ge kunden

”Vi utgår från minsta möjliga data. Vitec behåller grunddata och historik; vårt lager får endast den information som krävs för att planera, kommunicera och mäta piloten.”

Minimikrav inför pilot

SSO via Entra ID eller motsvarande, RBAC och least privilege.
Kryptering i transport och vila samt fullständig audit log.
Definierade gallringstider för cache, meddelanden och modellresultat.
Personuppgiftsbiträdesavtal, underbiträdeslista och bedömning av tredjelandsöverföring.
Ingen träning av externa modeller på kunddata utan uttryckligt avtal.
Mänsklig möjlighet att korrigera beslut och hantera undantag.

Den exakta personuppgiftsrollen och behovet av konsekvensbedömning beslutas tillsammans med Heimstadens dataskydds- och säkerhetsfunktion.

S14 S15

13

Hur undviker vi att bygga ett parallellt fastighetssystem?

Tydliga dataägare

Genom att begränsa vårt ansvar till planering. Vi använder Vitecs stabila ID:n, speglar bara den data som krävs temporärt och skriver tillbaka bokning/status där det är möjligt. Ärendedokumentation och historik avslutas i Vitec.

Svar att ge kunden

”Vår databas blir inte ett nytt fastighetsregister. Den innehåller integrationsstatus, optimeringsdata, bokningsstate och KPI – inte en konkurrerande master.”

Arkitekturprinciper

Vitec-ID är extern primärnyckel för alla synkade objekt.
Idempotenta kommandon och outbox/inbox-mönster minskar dubbla bokningar.
Datakontrakt versionshanteras; Vitec-specifika fält stannar i adaptern.
Cache har tidsgräns och kan återskapas från källsystemet.
Avvikelser visas i en integrationskö i stället för att döljas.

14

Vad händer när koncernens framtida fastighetssystem införs?

Byt adapter, behåll kärnan

Planeringsmotorn och användarflödena kan leva vidare. Om integrationen byggs bakom ett neutralt domänkontrakt ersätts Vitec-adaptern med en ny adapter, medan bokning, optimering, kommunikation och KPI kan återanvändas.

Svar att ge kunden

”Investeringen knyts till arbetsprocessen, inte till ett visst fastighetssystem. När koncernsystemet kommer byter vi koppling – inte hela lösningen.”

Exempel på neutralt integrationskontrakt

getCases(), getCase(), getProperty(), getTenantContact(), getResources(), updateAppointment(), updateAssignee() och updateStatus().

Domänmodellen bör använda neutrala begrepp och mappa Vitecs termer i adaptern. Det minskar migrationstid och leverantörslåsning.

Rekommenderad väg framåt

Börja med en teknisk beslutspunkt – därefter pilot

Teknisk förstudie

Bekräfta moduler, API, scopes, datafält, kalender, säkerhet och kontaktväg till Vitec.

Integrations-POC

Läs ett ärende, identifiera objekt och kontakt, läs tillgänglighet och prova skrivning tillbaka i sandbox.

Avgränsad pilot

Ett område, ett mindre team, några vanliga ärendetyper, enkel bokning och mänskligt godkänd omplanering.

Mätning och beslut

Jämför baseline mot utfall och besluta om fler ärendetyper, mer automation och produktionsmodell.

Tidplan: lämna inte ett bindande estimat före API-åtkomst. En rimlig plan kan först tas fram när integrationsprovet visar vad Heimstadens miljö faktiskt stödjer.

Det vi kan lova nu

Vi ersätter inte Vitec.
Vi använder officiella integrationsvägar.
Vi kan bygga och testa en optimeringsmotor.
Vi kan definiera en avgränsad pilot och mätbara KPI:er.
Arkitekturen kan göras migrerbar till framtida system.

Det vi inte ska lova ännu

Att alla önskade fält finns i Heimstadens API.
Att bokad tid och resurs kan skrivas tillbaka utan test.
Att Vitec erbjuder webhook för just detta flöde.
Att planeringen kan vara helt autonom från dag ett.
Exakt tidsbesparing, pris eller leveransdatum före baseline och POC.

Nästa kundmöte

Frågorna vi behöver få besvarade

Mötet bör landa i ett tydligt ja eller nej till en teknisk förstudie. Följande frågor avgör om piloten kan avgränsas och prissättas.

1

Vilka Vitec-produkter och moduler används?Teknisk Förvaltning, Arena, Evo Next, Hyra och eventuella kundunika delar.

2

Vilken version och driftsform?Moln/Evo eller äldre installation, samt aktuell uppgraderingsplan.

3

Vilka API:er är aktiverade?Evo API/Evo Connect, fastAPI arbetspaket 1, Arena API och DBAccess.

4

Kan vi få sandbox och dokumentation?Tekniskt konto, scopes, testdata, rate limits och kontaktperson hos Vitec.

5

Vilka fält kan läsas?Ärende, prioritet, objekt, adress, kontakt, resurs, status, planerad/faktisk tid.

6

Vilka fält kan uppdateras?Bokad start/slut, resurs, status, kommentar eller bokningsreferens.

7

Hur upptäcks förändringar?Webhook/event, delta/cursor, changed timestamp eller polling.

8

Hur används kalendern idag?Outlook/Microsoft 365, Vitecs Exchange-integration och eventuell annan planering.

9

Används Vitecs självbokning?Vilka områden, resurser och ärendetyper är bokningsbara i Arena?

10

Finns kompetens och geografisk koppling?Resursgrupper, resurser per fastighet, certifikat och arbetsområden.

11

Vilket område lämpar sig för pilot?Teamstorlek, ärendetyper, volym, geografisk avgränsning och lokal sponsor.

12

Hur mäter vi nuläget?Statuskontakter, administrativ tid, restid, duration, återbesök och kundnöjdhet.

13

Vilka säkerhetskrav gäller?SSO, EU/EES-hosting, loggning, DPA, underbiträden och retention.

14

Behövs Vitec-partnerskap eller godkännande?Licens, kostnadsmodell och lämplig väg via Integration/Solution Partner.

Beslut som mötet bör mynna ut i

Heimstaden utser Vitec-kunnig teknisk kontakt, ger tillgång till relevant dokumentation/sandbox och godkänner en kort integrations-POC med definierade acceptanskriterier.

Verifiering

Officiella källor bakom svaren

Vitec – API:er & integrationer. Evo API beskrivs med CRUD och möjlighet att hämta förändrad data; sidan beskriver även fastAPI och DBAccess. Öppna källa (kontrollerad 2026-08-30)
Vitec – Evo Connect öppnar för AI-drivna arbetssätt. Integrationsplattform, API-nycklar, åtkomststyrning och ekosystem för tjänster/agenter. Öppna källa (publicerad 2026-06-01)
Vitec – nytt partnerprogram. Solution Partners får utvecklarportal och sandbox; Integration Partners kopplar lösningar mot kunders miljöer. Öppna källa (publicerad 2026-08-28)
fastAPI – Work package. Arbetspaket 1 listar bland annat arbetsorder och felanmälan. Öppna källa
fastAPI – Fi2Order. Dokumentation för att läsa, skapa och uppdatera arbetsorder samt orderfält såsom prioritet och datum. Öppna källa
Vitec Teknisk Förvaltning – Självbokning Ärende och Besiktning. Hyresgäst kan boka/omboka i Arena; tider hämtas från Outlook; resurskoppling och notifieringar beskrivs. Öppna PDF (reviderad 2026-06-24)
Vitec Teknisk Förvaltning – Skapa och redigera nytt serviceärende. Beskriver fastighet, objekt, hyresgästkontakt, resurs, status, inställelsetid och kalenderkoppling. Öppna PDF
Vitec Teknisk Förvaltning – Automatisk tilldelning av åtgärder och ärenden. Beskriver automatisk tilldelning av handläggare, ansvarig och resurs samt koppling till fastighet/resursgrupp. Öppna PDF
Vitec Teknisk Förvaltning – Se åtgärdsstatistik. Statistik och filtrering på antal, tid, kostnad, typ, kategori och status. Öppna PDF
Vitec Teknisk Förvaltning – Avrapporteringsfliken. Beskriver status, avrapportering och registrering av tidsåtgång på åtgärder. Öppna PDF
Google OR-Tools – Vehicle Routing Problem with Time Windows. Officiell dokumentation för ruttoptimering med tidsfönster. Öppna källa
Microsoft Graph – calendar:getSchedule. Officiellt API för free/busy-tillgänglighet för användare och resurser. Öppna källa
Microsoft Graph – change notifications. Officiell dokumentation för händelsenotifieringar via bland annat webhooks. Detta avser Microsoft Graph, inte bekräftat webhook-stöd i Vitec. Öppna källa
IMY – grundläggande principer enligt GDPR. Ändamål, rättslig grund, transparens, dataminimering och riktighet. Öppna källa
IMY – personuppgiftsbiträdesavtal. Krav och ansvar för personuppgiftsbiträde och underbiträden. Öppna källa

Avgränsning: publika källor visar vad produkterna och standarderna stödjer generellt. De bevisar inte att alla funktioner, endpoints, licenser och behörigheter är aktiva i Heimstadens specifika tenant. Det är därför sandbox-/API-verifieringen är projektets första beslutspunkt.