Integrasjon er ikke et teknologiprosjekt. Det er arbeidet med å gjøre en reservasjon om til et klart rom uten en telefonsamtale, en gjestemelding om til en oppgave med en ansvarlig, og en feil om til en reparasjon med en frist. Med et stramt omfang passer dette arbeidet inn i 30 dager på et hvilket som helst PMS med et dokumentert API, og planen nedenfor viser rekkefølgen, de ansvarlige og kontrollene.

Hvem denne planen er for

• Systemansvarlige og IT-ledere som trenger et omfang og en tidsplan de kan forsvare

• Driftsdirektører og hotelldirektører som vil se verdi før høysesongen

• Ledere i housekeeping og vedlikehold som er opptatt av pålitelig status og færre telefoner

Planen forutsetter et skybasert PMS med API-tilgang, for eksempel Mews, Apaleo, Oracle OPERA Cloud, Cloudbeds eller Guestline, og ett enkelt hotell eller ett hotell i en kjede som pilot.

Hva må være på plass før dag én?

Fire ting, og mangler én av dem, har klokken ikke begynt å gå.

1. API-tilgang er gitt, ikke bare lovet. Ansvarlig: systemansvarlig eller IT-leder. Varighet: sett av én til to uker før dag én, siden det er dette trinnet leverandører forsinker. Du trenger påloggingsinformasjon, de dokumenterte grensene for antall forespørsler og, der det tilbys, et testmiljø. Mews publiserer sine endepunkter i dokumentasjonen for Mews Connector API, og Apaleo publiserer sine på apaleo.dev, så du kan lese begrensningene før du binder deg til et omfang.

2. En navngitt sponsor i ledelsen. Ansvarlig: hotelldirektør. Varighet: én samtale. Noen må kunne si nei når omfanget begynner å vokse i uke tre.

3. Et skriftlig utgangspunkt. Ansvarlig: housekeepingsjef og resepsjonssjef. Varighet: en halv dag. Registrer dagens gjennomsnittlige klargjøringstid for rom, andel oppgaver fullført i tide og antall telefoner per vakt mellom resepsjonen og housekeeping. Uten dette kan du ikke bevise at prosjektet virket.

4. Et avgrenset pilotområde. Ansvarlig: housekeepingsjef. Varighet: én time. Én etasje, ett skift, én supervisor.

Bør integrasjonen være enveis eller toveis?

Velg mønsteret som passer leverandøren din og hvor mye risiko du tåler, og start enkelt.

Start enveis hvis du er usikker. Legg til tilbakeskriving i måned to når teamet stoler på det det ser. Sweeply støtter begge mønstrene i sine 20+ PMS-integrasjoner, så beslutningen handler om driften din og ikke om koblingen.

30-dagersplanen: åtte trinn med ansvarlig og varighet

1. Bli enige om bruksområdene og frys omfanget. Ansvarlig: sponsor i ledelsen. Varighet: dag 1 til 2. Fire bruksområder er riktig antall for en første versjon: synkronisering av romstatus, housekeepingoppgaver opprettet fra utsjekkinger, gjesteforespørsler som blir oppgaver, og overleveringer til vedlikehold. Alt annet havner på en liste merket «fase to».

2. Definer statusene i klarspråk. Ansvarlig: housekeepingsjef, sammen med resepsjonssjefen. Varighet: dag 3 til 5. Skriv ned hva rent, skittent, pågår, inspisert, klart, ute av drift og ute av bruk faktisk betyr på ditt hotell, og hvilke overganger som er tillatt. De fleste integrasjonsfeil kan spores tilbake til at denne halve siden ikke finnes.

3. Kartlegg rom, romtyper og etasjer. Ansvarlig: systemansvarlig. Varighet: dag 6 til 8. Lag én autoritativ referansetabell og hold den under versjonskontroll. Alle senere avvik feilsøkes mot denne tabellen.

4. Konfigurer oppgavetyper, prioriteter og responstider. Ansvarlig: housekeepingsjef og leder for teknisk avdeling sammen. Varighet: dag 9 til 12. Koble kategorier for gjesteforespørsler til oppgavetyper, sett frister, og bestem hvem en forsinket oppgave eskaleres til. Sweeplys moduler for housekeeping og vedlikehold konfigureres i dette trinnet.

5. Fastsett roller, tilganger og dataminimering. Ansvarlig: systemansvarlig, sammen med personvernansvarlig. Varighet: dag 13 til 15. Hent bare feltene arbeidet krever, begrens gjestedata til rollene som trenger dem, og slå på revisjonslogger. Sweeplys vilkår for hosting, kryptering og databehandling er publisert på sikkerhetssiden hvis innkjøp spør.

6. Kjør pilot på én etasje og ett skift. Ansvarlig: housekeepingsjef. Varighet: dag 16 til 20, med tre til fem dager i drift. Følg reelle skift i stedet for å lese rapporter. Loggfør hvert hull i kartleggingen og hvert øyeblikk en romassistent nøler.

7. Rett opp, og hold deretter et beslutningspunkt for å gå videre eller stoppe. Ansvarlig: sponsor i ledelsen. Varighet: dag 21 til 24. Sammenlign klargjøringstid og andel fullført i tide fra piloten med utgangspunktet fra før dag én. Hvis tallene ikke har flyttet seg, finn ut hvorfor før du skalerer problemet.

8. Rull ut trinnvis og stabiliser. Ansvarlig: hotelldirektør, med én leder per avdeling. Varighet: dag 25 til 30, pluss to uker med daglige kontroller. Rull ut etasje for etasje eller bygg for bygg, sjekk API-helsen og forsinkede oppgaver hver morgen, og før en synlig avvikslogg slik at tilliten vokser.

To publiserte utrullinger er verdt å lese sammen med denne planen. STAYERY gikk fra regneark til automatisert planlegging av rengjøring under oppholdet på Apaleo (kundehistorien om STAYERY), og Volkshotel Amsterdam holdt driften i gang med 196 rom og et team med 33 nasjonaliteter gjennom en migrering til Mews (kundehistorien om Volkshotel).

Hvilke data må faktisk stemme overens?

Fire objekter står for nesten all risikoen. Bli enige om feltene deres før du konfigurerer noe.

Skriv ned de tillatte statusovergangene som en rekkefølge, for eksempel skittent til pågår til rent til inspisert til klart, og hold den kort. Hver ekstra status er en status noen må få opplæring i.

Hvordan vet du at det fungerer?

Følg fem tall ukentlig de to første månedene, deretter månedlig:

• Andel rom som tildeles automatisk i stedet for manuelt

• Gjennomsnittlig klargjøringstid for rom sammenlignet med utgangspunktet før integrasjonen

• Andel gjesteforespørsler og arbeidsordrer for vedlikehold som fullføres i tide

• Feilrate og gjennomsnittlig forsinkelse i API-et

• Telefoner per vakt mellom resepsjonen og housekeeping

Det siste tallet er det de ansatte merker først. Blant Sweeplys kunder faller koordineringstiden typisk med rundt 20 %, og det er den kapasiteten prosjektet faktisk gir tilbake.

Hva går i stykker, og hvordan fikser du det raskt?

Tre feil står for de fleste supporthenvendelser. Statusavvik, der PMS-et viser et rom som klart og housekeeping viser det som skittent, løses med en daglig avstemmingsjobb som sammenligner begge romlistene og flagger forskjeller i stedet for å overskrive dem i det stille. Feil ved levering av webhooks løses med nye forsøk med økende ventetid, pluss den samme avstemmingen som sikkerhetsnett. Feltendringer hos leverandøren etter en API-oppdatering løses ved å versjonere kartleggingstabellen, slik at du kan se hva som ble endret og rulle tilbake.

Ha en skriftlig eskaleringsvei, inkludert hva PMS-leverandøren din trenger fra deg for å undersøke: tidsstempel, endepunkt, forespørsels-ID og det berørte rommet.

Når 30 dager er feil plan

Denne planen forutsetter forhold som ikke alle hoteller har, og det er bedre å vite det i uke null.

• Lokalt installert PMS uten API, eller grensesnittilgang som koster penger. Integrasjonen kan likevel være verdt å gjøre, men tidsplanen styres av leverandørens kommersielle prosess, ikke av denne planen. Hent inn pristilbud på grensesnittet før du planlegger noe annet.

• Flere PMS-instanser i en kjede. Gjør ett hotell helt ferdig først. Å kjøre fire hoteller på tre PMS-versjoner parallelt gjør en 30-dagersplan om til en plan på seks måneder.

• Svært små overnattingssteder. Under rundt 25 rom med én romassistent gir en delt oppgaveliste det meste av gevinsten, og et formelt integrasjonsprosjekt er ekstraarbeid du ikke trenger.

• Der Sweeply ikke er svaret. Sweeply er et driftslag oppå PMS-et, ikke et PMS, en integrasjonsplattform eller en mellomvarelisens. Hvis det du trenger, er en generell dataflyt mellom økonomi-, kasse- og BI-systemer, er det et annet verktøy og et annet prosjekt.

Start samtalen om kartlegging

Book en samtale med salgsteamet vårt og oppgi navn og versjon på PMS-et ditt, antall rom og ønsket oppstartsdato. Vi bekrefter at integrasjonen støttes, og forteller deg hvilke av de fire objektene ovenfor som trenger kartleggingsarbeid i ditt tilfelle.