Teknikintegration för hotell

Den här sidan är för dig som redan har flera system i drift — PMS, kanalhanterare, låssystem, betalterminal, gästwifi — och känner att de inte pratar tillräckligt bra med varandra, eller som står inför att välja nya system och vill undvika att fastna i en lösning som är dyr att ta sig ur.

Så går det till

1. Kartläggning — genomgång av samtliga system som är i drift idag: PMS, kanalhanterare, låssystem, betalterminal, wifi/gästportal, ev. bokningsmotor och revenue management, samt vilka av dem som redan pratar med varandra och hur.
2. Identifiering av integrationsbehov — vilka kopplingar saknas, vilka är trasiga eller manuella idag (t.ex. dubbel inmatning i två system), och vad som faktiskt ger effekt att åtgärda först.
3. Leverantörsutvärdering — de befintliga leverantörernas API:er och integrationsmöjligheter granskas, eventuella nya leverantörer utvärderas mot samma kriterier.
4. Avtalsgenomgång — krav på dataportabilitet, ansvarsfördelning och uppsägningsvillkor säkerställs innan något skrivs under (se "Vanliga fallgropar").
5. Implementation och test — integrationerna byggs eller aktiveras, och hela flödet testas end-to-end innan det tas i skarp drift.
6. Driftsättning med övervakning — en period efter lansering där flödet bevakas extra noga, så fel upptäcks innan de hinner orsaka dubbelbokningar eller förlorade betalningar.

Vilka integrationer, och var de brukar gå sönder

PMS som nav. Property management-systemet är i praktiken navet — kanalhanterare, låssystem, betalterminal och gästportal kopplas normalt alla mot PMS:et snarare än mot varandra direkt.

Kanalhanterare (channel manager). Synkar tillgänglighet och priser mot bokningskanaler som Booking.com och Expedia. Vanlig felkälla: nätverksavbrott eller fördröjning mellan kanalhanterare och PMS som gör att en tillgänglig natt säljs två gånger innan systemen hinner synka — grunden till dubbelbokningar.

Låssystem. Se den separata sidan om RFID-implementering för det tekniska djupet där. Ur ett integrationsperspektiv är felkällan oftast att rumsnummer eller incheckningstid inte förs över korrekt från PMS till kortkodningen.

Betalterminal. Måste både klara PCI DSS-kraven för kortbetalningar och passa in i PMS:ets utcheckningsflöde. Vanlig felkälla: en uppdatering hos betalleverantören som ändrar hur transaktionen rapporteras tillbaka till PMS, utan att det kommuniceras till hotellet i förväg.

Wifi och gästportal. Fungerar bäst när gästens inloggning kopplas automatiskt till rumsnummer/bokning via PMS, istället för ett separat lösenord som receptionen delar ut manuellt. Vanlig felkälla: kopplingen mellan portal och PMS bryts vid en systemuppdatering på endera sidan, och ingen märker det förrän gäster börjar klaga.

Hur leverantörer bör utvärderas. Kräv att se dokumenterade, helst öppna API:er — inte bara ett löfte om att "integration finns". Fråga efter referenser från hotell av liknande storlek som faktiskt kör den specifika integrationen ni är ute efter, inte bara samma system i allmänhet. Be om leverantörens rutin för att kommunicera API-ändringar i förväg.

Vad avtalet bör innehålla. Rätt att exportera er egen data (bokningshistorik, gästregister) i ett användbart format. Tydlig ansvarsfördelning för vem som åtgärdar ett integrationsfel och inom vilken tid. Uppsägningsvillkor som inte straffar er orimligt hårt för att byta bort en del av systemet senare.

Hur man undviker inlåsning. Undvik att låsa PMS, betalning och kanalhantering till en enda leverantörs helhetspaket utan en tydlig exitplan. Testa själva exportrutinen innan avtal skrivs på — inte bara läsa att den finns i avtalstexten.

Vanliga fallgropar

• Att anta att "stödjer integration" betyder testat och klart för just er kombination av system — be om en referens som kör exakt den kopplingen.
• Att inte testa hela flödet end-to-end — från bokning via OTA, till PMS, till kanalhanterare, till betalning — innan lansering.
• Att ingen äger supportansvaret när ett fel uppstår i gränssnittet mellan två system, och båda leverantörerna pekar på varandra.
• Att sakna en manuell reservrutin för det som händer om integrationen ligger nere under hög beläggning.
• Att välja en allt-i-ett-lösning utan att ha tänkt igenom vad som händer om ni vill byta bort en enskild del senare.
• Att inte begära API-dokumentation innan avtal skrivs, och istället lita på muntliga löften från säljare.

Vad det kostar

Kostnaden styrs av hur många system som ska kopplas ihop, om det rör sig om färdiga standardkopplingar eller om något behöver specialbyggas, och hur mycket av det tekniska arbetet som redan finns hos era nuvarande leverantörer. Vi kartlägger er nuvarande systemmiljö först, och tar fram en verklig kostnadsbild utifrån det snarare än ett schablonpris.

Vanliga frågor

Vilka system måste egentligen prata med varandra?

I grunden PMS och de system som direkt påverkar bokning, incheckning och betalning — kanalhanterare, låssystem och betalterminal. Wifi/gästportal är önskvärt men mindre kritiskt om det brister tillfälligt.

Kan vi byta kanalhanterare utan att byta PMS?

I de flesta fall ja, så länge PMS:et har ett öppet gränssnitt mot kanalhanterare i allmänhet och inte bara mot en specifik leverantör.

Vad händer om en integration går sönder mitt i högsäsong?

Det är precis därför avtalet bör innehålla tydlig ansvarsfördelning och svarstider innan ni skriver på — och varför en manuell reservrutin behöver finnas, inte bara en förhoppning om att det aldrig händer.

Behöver vi en egen IT-avdelning för att sköta det här?

Nej, men någon — internt eller extern konsult — behöver ha helhetsbilden av hur systemen hänger ihop, så att ni inte står med flera leverantörer som var för sig säger att allt fungerar på deras sida.

Är molnbaserade system säkrare eller sämre än lokala servrar?

Det beror mer på leverantörens säkerhetsarbete än på om lösningen är molnbaserad eller lokal. Fråga efter deras säkerhetsrutiner och vilka certifieringar de har, oavsett driftsform.

Hur vet vi att en leverantör verkligen kan integrera, och inte bara säger det?

Be om en referenskund som kör exakt den kombinationen ni är ute efter, och be om att få se API-dokumentationen innan ni skriver på.

Kan ni hjälpa oss utvärdera system vi redan har, eller bara sätta upp nya?

Båda delarna — en genomgång av befintlig systemmiljö är ofta precis det som avslöjar var de dyraste problemen faktiskt sitter.