Slik skriver du en anbudsforespørsel for hotelladministrasjonssystemer

Å skrive en RFP for system for eiendomsforvaltning på hotell er et av de smarteste grepene du kan ta før du forplikter deg til et nytt system. En forespørsel om tilbud (RFP) er et formelt dokument du sender til leverandører, der du ber dem svare på dine spesifikke krav, spørsmål og kriterier.

Bruk en slik forespørsel når du vurderer flere leverandører og trenger strukturerte, sammenlignbare svar – ikke salgspresentasjoner.

En velskrevet RFP tvinger leverandørene til å ta for seg dine faktiske behov, i stedet for å presentere standarddemonstrasjonen sin. Den skaper ansvarlighet på begge sider og gir teamet ditt et ensartet rammeverk for evaluering. Resultatet er en kortliste basert på fakta, ikke inntrykk.

Trenger du faktisk en RFP?

En RFP er ikke alltid det riktige verktøyet – men når du skal ta en programvarebeslutning med mye på spill, er den ofte det beste valget. For systemer for eiendomsforvaltning på hotell gir prosessen størst utbytte når evalueringen innebærer reell kompleksitet eller krav til organisatorisk ansvarlighet. En RFP er fornuftig i situasjoner som disse:

• Du vurderer tre eller flere leverandører samtidig.
• Eiendommen din har flere avdelinger, lokasjoner eller integrasjonskrav.
• En innkjøpskomité eller eiergruppe trenger dokumentert begrunnelse.
• Du erstatter et eksisterende system, og det er behov for omfattende datamigrering.
• Budsjettgodkjenning krever en formell konkurransebasert anbudsprosess.

Når en RFP kan være unødvendig omfattende

Hvis du driver en liten, uavhengig eiendom med enkle behov og en kortliste på én eller to leverandører du allerede stoler på, vil en strukturert leverandørdemonstrasjon og en tydelig spørsmålsliste sannsynligvis være tilstrekkelig. Dropp RFP-en når hurtighet er viktigere enn prosessen, og beslutningen din ikke krever godkjenning utenfra.

RFI vs. RFP vs. RFQ: Hva er forskjellen?

En RFI innhenter informasjon, en RFP ber om løsningsforslag, og en RFQ ber om konkrete priser. Ikke alle kjøp av systemer for eiendomsforvaltning på hotell krever en RFP, særlig ikke når kravene og den foretrukne løsningen allerede er tydelige. Ved å velge riktig dokument gir du leverandørene riktig retning og hjelper teamet ditt med å sammenligne svarene på en rettferdig måte.

Bruk denne tabellen for å knytte hvert anskaffelsesdokument til behovene dine ved kjøp av programvare:

Vanlige RFP-feil du bør unngå

Svake RFP-er lar leverandørene gjette seg frem til informasjon om eiendommen, prioriteringene og begrensningene dine ved kjøpet. Det kan føre til vage svar, uensartede priser og tilbud som er vanskelige å sammenligne. Vanlige feil omfatter å bruke brede krav, la ansvarsområder være udefinert, overse implementeringsbehov og unnlate å spesifisere hvordan leverandørene skal forklare begrensninger eller tilleggskostnader.

Unngå disse feilene for å gjøre leverandørenes svar mer nyttige og sammenlignbare:

For lite bakgrunnsinformasjon eller kontekst

Forklar eiendomstypen, antall rom, lokasjoner, avdelinger, nåværende system og prosjektmålene. Uten denne konteksten kan leverandører foreslå uegnede konfigurasjoner eller overse krav som rapportering på tvers av flere eiendommer, arbeidsflyter for renhold eller behov for migrering. Inkluder en kort beskrivelse av eiendommen og beskriv de driftsmessige problemene det nye systemet må løse.

Manglende eller uklart budsjett

Oppgi forventet budsjettintervall eller be om en fullstendig oversikt over engangskostnader og løpende kostnader. Uten tydelige prisføringer kan leverandører foreslå løsninger som overstiger godkjenningsgrensen, eller utelate kostnader for implementering, integrasjoner, opplæring, brukerstøtte og datamigrering. Be leverandørene om å skille mellom hver kostnad og identifisere valgfrie gebyrer.

Vage krav eller juridisk sjargong

Skriv kravene i et enkelt språk og beskriv hvilket resultat teamet trenger fra hver funksjon. Vage formuleringer fører til ulike tolkninger, mens overdreven juridisk språkbruk kan skjule viktige driftsdetaljer. Bruk konkrete spørsmål, for eksempel hvordan systemet håndterer romtildelinger, prisbegrensninger, revisjonsspor og tilgang til gjestedata.

Ingen delte evalueringskriterier

Fortell leverandørene hvordan dere vil vurdere forslagene før de svarer. Uten delte kriterier kan leverandørene fokusere på sine foretrukne salgsargumenter, og teamet deres kan vurdere svarene på en uensartet måte. Tildel vekter til områder som funksjonalitet, integrasjoner, implementering, brukerstøtte, sikkerhet, brukervennlighet og totalkostnad.

Ingen standardformat for leverandørsvar

Gi alle leverandørene den samme svarmalen, spørsmålsrekkefølgen og prisformatet. Ustrukturerte forslag gjør det vanskeligere å sammenligne inkluderte funksjoner, forutsetninger, tjenestenivåer, kontraktsvilkår og unntak. Krev at leverandørene svarer direkte på hvert krav og merker svarene som inkludert, konfigurerbart, skreddersydd, utilgjengelig eller avklaringskrevende.

Join our Community

Keep up with the hotel management community!

Get Free Access

Have an account? Log In

Sett sammen RFP-teamet for programvaren for hotelladministrasjon

Et tverrfunksjonelt team hjelper dere med å kartlegge driftsbehov, innkjøpsbegrensninger og tekniske krav før leverandørene sender inn forslag. Det skaper også et felles eierskap, slik at den endelige beslutningen gjenspeiler hvordan eiendommen faktisk drives.

Involver disse gruppene for å utarbeide en praktisk RFP og vurdere leverandørsvar på en rettferdig måte:

Prosjekteier

Daglig leder, eier, driftsdirektør eller regional driftsdirektør kan være prosjekteier for RFP-en for programvare for hotelladministrasjon. Denne personen fastsetter prosjektprioriteringer, bekrefter budsjettforventninger, løser motstridende krav og gir den endelige godkjenningen.

Fageksperter

Resepsjonssjefen, romdivisjonssjefen, inntektsansvarlig, renholdssjefen, økonomiansvarlig og IT-sjefen kan definere avdelingenes krav. De bør forklare nåværende arbeidsflyter, identifisere integrasjonsbehov, påpeke mangler i rapporteringen og vurdere om de foreslåtte funksjonene støtter den daglige driften.

Innkjøpsansvarlige eller RFP-forfattere

En innkjøpssjef, innkjøpsspesialist, prosjektleder eller forretningsanalytiker kan organisere RFP-prosessen. Denne gruppen utarbeider svarmalen, fastsetter tidsfrister, standardiserer prisforespørsler, dokumenterer forutsetninger og koordinerer spørsmål fra leverandørene.

Sluttbrukere og interessenter

Resepsjonister, reservasjonsmedarbeidere, renholdere, nattevakter, eiendomsregnskapsførere og representanter for eierne kan beskrive praktiske behov og beslutningsmessige bekymringer. Tilbakemeldingene deres bidrar til å teste brukervennlighet, identifisere opplæringsbehov, vurdere tilgangstillatelser og bekrefte at forslagene passer til de faktiske arbeidsflytene for gjesteservice.

Definer ufravikelige krav & mål

Definer hva den nye programvaren for hotelladministrasjon må kunne gjøre før dere ber leverandørene om forslag. Tydelige utfordringer, mål og ufravikelige krav hjelper leverandørene med å rette svarene direkte mot driften deres og gjør det enklere å sammenligne svarene.

Bruk disse områdene til å definere kravene dine:

• Problempunkter i dagens system: Beskriv hvor det eksisterende systemet ditt fører til forsinkelser, feil eller dobbeltarbeid. Forklar for eksempel om resepsjonsmedarbeidere legger inn bestillingsopplysninger på nytt, om renholdspersonalet mangler oppdateringer om romstatus i sanntid, eller om ledere eksporterer rapporter manuelt.

• Påkrevde forbedringer og ønskede resultater: Knytt hver forespurte funksjon til et målbart driftsresultat. Det kan være behov for raskere innsjekkingsprosesser, færre avvik i romstatus, mer nøyaktige beleggsrapporter eller bedre oversikt over vedlikeholdsoppgaver.

• Funksjonelle, tekniske og regulatoriske behov: List opp nødvendige funksjoner innen reservasjoner, fakturering, renhold, rapportering, integrasjoner med regnskapsprogramvare for hoteller, sikkerhet og databeskyttelse. Spesifiser krav som betalingsbehandling, regnskapsintegrasjon, rollebasert tilgang, revisjonslogger, oppbevaring av data og overholdelse av gjeldende personvernforpliktelser.

• Brukerroller, bruksnivåer og arbeidsflyter: Identifiser alle brukergrupper, forventet antall brukere, tilgangsnivå og viktigste arbeidsflyt. Ta med resepsjonsmedarbeidere, nattevakter, renholdere, inntektsansvarlige, økonomimedarbeidere og regionale operatører, samt perioder med høy belastning under ankomster eller vaktskifter.

• Preferanser for distribusjon: Oppgi om du foretrekker skybasert, lokalt driftet eller hybrid distribusjon. Forklar krav til nettlesertilgang, mobile arbeidsflyter, robusthet ved internettbrudd, konfigurasjon på eiendomsnivå, oppdateringer, datalagring og leverandørstyrt infrastruktur.

Skriv RFP-en for programvare for hotelladministrasjon

Når målene, kravene og interessentene er definert, er neste steg å omforme dem til en målrettet RFP. Et velorganisert dokument gir leverandørene tydelig retning og hjelper teamet med å sammenligne funksjonalitet, implementeringsplaner, priser og brukerstøtte. Ta med disse delene i RFP-en:

1. Sammendrag

Beskriv eiendommen, prosjektmålene, det nåværende systemet og hvorfor dere ser etter ny programvare. Nevn detaljer som antall rom, type eiendom, antall lokasjoner og planlagt beslutningsdato. Forklar hvilke resultater dere forventer, for eksempel én reservasjonsoppføring på tvers av avdelinger eller bedre oversikt over romstatus.

2. Arbeidsomfang

Definer tjenestene og programvarefunksjonene leverandørene må tilby. Ta med reservasjoner, resepsjonsdrift, renhold, vedlikehold, fakturering, rapportering, integrasjoner, migrering, brukerstøtte og administrasjon av flere eiendommer der det er relevant. Be for eksempel leverandørene forklare hvordan systemet håndterer rombytter, gruppebestillinger, delte betalinger og rom som er tatt ut av drift.

3. Tekniske krav

List opp de tekniske betingelsene teamet forventer at plattformen oppfyller. Ta for deg distribusjonsmodell, støttede nettlesere og enheter, mobiltilgang, API-er, integrasjoner, dataeksport, mål for oppetid, sikkerhetskopieringsprosesser og ytelse under perioder med mange ankomster. Spesifiser eksisterende systemer, for eksempel plattformer for regnskap, betaling, kassasystemer, bestillingsmotor for hotell, kanaladministrasjon eller identitetsadministrasjon.

4. Leverandørens kvalifikasjoner

Be leverandørene dokumentere at de kan støtte eiendommer som ligner på din. Be om informasjon om selskapets historie, kunder innen hotellbransjen, relevant implementeringserfaring, brukerstøttelokasjoner, økonomisk informasjon og referanser. Spør referansene om nøyaktigheten ved migrering, responstider, systemtilgjengelighet, kvaliteten på opplæringen og hvordan leverandøren håndterte uløste problemer.

5. Krav til sikkerhet og samsvar

Oppgi kravene deres til beskyttelse av gjeste-, betalings-, ansatt- og virksomhetsdata. Be leverandørene beskrive tilgangskontroller, flerfaktorautentisering, kryptering, revisjonslogger, testing av sårbarheter, hendelseshåndtering, lagring av data og underleverandører. Inkluder gjeldende forpliktelser, for eksempel krav til betalingskort og personvernlover som berører gjestene eller driftsstedene deres.

6. Forventninger til implementering og opplæring

Beskriv implementeringstjenestene dere trenger, inkludert kartlegging, konfigurering, datamigrering, integrasjonstesting, brukerakseptansetesting, støtte ved lansering og gjennomgang etter lansering. Fastsett forventninger til prosjektmilepæler, leverandøransvar, eiendomsansvar og eskaleringsprosedyrer. Be leverandørene legge frem en opplæringsplan for resepsjonsmedarbeidere, nattevakter, renholdsteam, ledere og administratorer.

7. Priser og lisensiering

Krev at leverandørene skiller mellom abonnementsavgifter, oppsettskostnader, implementeringstjenester, integrasjoner, migrering, opplæring, støtte, maskinvare, skatter og valgfrie moduler. Definer prisgrunnlaget, for eksempel rom, eiendommer, brukere, transaksjoner eller bruksnivåer. Be om totalpriser for tre eller fem år, prisøkninger ved fornyelse, minimumsforpliktelser og gebyrer for å legge til rom eller lokasjoner.

8. Kontraktsvilkår

Spesifiser de kommersielle og juridiske vilkårene organisasjonen deres forventer at leverandørene skal ta stilling til. Dekk kontraktslengde, fornyelser, oppsigelsesrettigheter, tjenestenivåer, responstider for brukerstøtte, eierskap til data, eksport av data, konfidensialitet, ansvar, forsikring, prisendringer og underleverandører. Be leverandørene identifisere unntak fra vilkårene deres og legge ved en versjon med endringer markert av eventuelle foreslåtte avtaler.

9. Krav til leverandørenes svar

Be leverandørene strukturere svarene sine i et enhetlig format, slik at teamet deres lettere kan sammenligne tilbudene. Krev at de tar stilling til hvert funksjonelle krav, angir om funksjonene er standard, konfigurerbare, spesialutviklede eller utilgjengelige, og forklarer eventuelle avhengigheter, begrensninger eller tilleggskostnader. Dere kan også be leverandørene oppgi hvor integrasjoner med tredjeparter eller implementeringstjenester er nødvendige.

Definer evalueringskriteriene deres

Fastsett evalueringskriteriene før leverandørene sender inn tilbud, særlig når flere avdelinger skal vurdere ulike funksjoner. Bestem hvilke faktorer som betyr mest – for eksempel funksjonalitet, brukervennlighet, integrasjoner, implementering, støtte og totalkostnad – og tildel hver faktor en vekt basert på hvor viktig den er. Ved å bruke den samme vektede poengmodellen for hvert tilbud kan teamet deres evaluere leverandørene på en ensartet måte og sørge for at beslutningene er knyttet til driftsmessige prioriteringer.

Hva betyr mest?

Velg tre til fem vektede kategorier som gjenspeiler prosjektmålene og driftsprioriteringene deres. En hotellgruppe med flere eiendommer kan for eksempel legge større vekt på rapportering og sentral administrasjon, mens et uavhengig hotell kan prioritere arbeidsflyter i resepsjonen og implementeringsstøtte. Vurder disse vanlige poengkategoriene, og velg deretter bare dem som betyr mest for teamet deres:

• Funksjonell tilpasning
• Integrasjonsmuligheter
• Implementeringsplan
• Brukeropplevelse
• Rapportering og analyse
• Sikkerhet og samsvar
• Støtte og opplæring
• Totalkostnad
• Leverandørerfaring
• Kontraktsvilkår

Bruk en poengmatrise

Lag en poengmatrise med én rad for hvert kriterium og én kolonne for hver leverandør. Dere kan for eksempel tildele funksjonell tilpasning 30 %, integrasjoner 20 %, implementering 15 %, støtte 15 %, sikkerhet 10 % og totalkostnad 10 %, og deretter justere vektene etter egne prioriteringer. Be vurdererne gi poeng for hvert kriterium på en ensartet skala fra 1–5 eller 1–10, og multipliser hver poengsum med den tildelte vekten. Hvis migreringsrisiko er den største bekymringen, bør dere øke vekten for implementering i stedet for å la alle kategorier telle likt.

Avklar poenggivingsprosessen

Definer hvem som skal vurdere tilbudene, og hvilke bevis vurdererne bør ta hensyn til før svarene kommer inn. Inkluder representanter fra resepsjonen, renhold, økonomi, IT, inntektsstyring og eiersiden når ansvarsområdene deres påvirker innkjøpet. Bruk en standardisert vurderingsmatrise med beskrivelser for hver poengsum, og planlegg deretter et kort avklaringsmøte slik at vurdererne tolker kravene på samme måte før poenggivningen begynner. Krev skriftlige kommentarer for uvanlig høye eller lave poengsummer, for eksempel ved manglende integrasjon med regnskapssystemet eller en uklar opplæringsplan.

Send ut RFP-en for hotelladministrasjonsprogramvaren

Distribuer RFP-en gjennom en tydelig og kontrollert prosess, slik at alle leverandører mottar den samme informasjonen og får like lang tid til å svare. En konsekvent prosess gir også teamet ditt en pålitelig oversikt over spørsmål, frister og innleveringer. Bruk denne fremgangsmåten:

Velg riktig distribusjonsmetode

Send RFP-en direkte på e-post, publiser den gjennom en innkjøpsportal eller inviter leverandører gjennom en sentralisert plattform for innkjøp. For de fleste søk etter hotellprogramvare anbefaler jeg et sentralisert system som registrerer dokumenttilgang, leverandørspørsmål, mottak av tilbud og revisjonshistorikk på ett sted. Inkluder en kontaktliste for leverandører eller bruk en rollebasert innboks, for eksempel pms-rfp@yourhotel.com, slik at kommunikasjonen forblir tydelig når flere teammedlemmer håndterer prosessen.

Angi tydelige forventninger til tidsplanen

Publiser alle milepæler i selve RFP-en, inkludert tidssone og om datoene gjelder kalenderdager eller virkedager. En praktisk tidsplan for et søk etter hotelladministrasjonsprogramvare kan se slik ut:

• Dato for utsendelse av RFP: Send det endelige dokumentet og svarmalen til alle inviterte leverandører.
• Periode for spørsmål og svar fra leverandører: Sett av fem til sju virkedager til spørsmål, og del deretter svarene med alle deltakende leverandører.
• Frist for endelig innlevering: Gi leverandørene to til tre uker til å utarbeide tilbudene sine etter at de har mottatt RFP-en.
• Periode for evaluering og valg: Sett av én til to uker til poenggiving, demonstrasjoner, referansesjekker og valg av finalister.

Varsle leverandørene raskt hvis en milepæl endres, og gi alle deltakende leverandører en eventuell utsettelse samtidig.

Definer kravene til innlevering

Fortell leverandørene nøyaktig hvordan tilbudene skal leveres, for eksempel PDF for den skriftlige besvarelsen, XLSX for priser og DOCX for utfylte spørreskjemaer. Angi leveringsmetoden, for eksempel en innkjøpsportal, en sikker opplastingslenke eller en rollebasert innboks, og oppgi om leverandørene må bruke malene eller skjemaene dine. Forklar også tidssonen for fristen, tilbudets gyldighetsperiode, filstørrelsesbegrensninger, navnekonvensjon og om sene innleveringer vil bli avvist eller bare akseptert med skriftlig godkjenning.

Evaluer leverandørsvar og lag en kortliste

Vurder hvert tilbud opp mot kravene og evalueringsrammeverket du etablerte tidligere. Sammenlign dokumenterte funksjoner, prisforutsetninger, tidsplaner for implementering, supportforpliktelser og eventuelle unntak leverandørene har identifisert. Bruk resultatene til å begrense feltet til leverandørene som fortjener grundigere validering gjennom demonstrasjoner, referansesjekker eller oppfølgingsspørsmål:

• Standardiser gjennomgangen av tilbudene: Konverter hvert svar til det samme regnearket eller den samme sammenligningstabellen. Registrer om hvert krav er inkludert, konfigurerbart, spesialtilpasset, utilgjengelig eller uklart, og noter forutsetninger om integrasjoner, antall brukere og support.

• Bruk en vektet poengmatrise: Gi poeng for funksjonell egnethet, integrasjoner, implementering, support, sikkerhet, brukervennlighet og totalkostnad ved hjelp av avtalte vekter. Du kan for eksempel legge større vekt på migrering og opplæring når et system skal erstattes før høysesongen.

• Planlegg strukturerte demonstrasjoner: Gi hver finalist identiske scenarier i stedet for å tillate generiske presentasjoner. Be leverandørene demonstrere rombytte, delt betaling, gruppebestilling, oppdatering av rengjøringsstatus, nattaudit og regnskapseksport ved hjelp av arbeidsflytene dine.

• Intervju leverandørens referanser: Snakk med hoteller som har tilsvarende antall rom, eiendomstyper, integrasjoner eller behov på tvers av flere eiendommer. Spør referansene om migreringsnøyaktighet, responstider for support, kvaliteten på opplæringen, systemtilgjengelighet og uløste problemer med implementeringen.

• Avklar mangler i tilbudet: Send skriftlige spørsmål når priser, funksjonalitet, tidsplaner eller kontraktsvilkår virker uklare. Spør om en etterspurt funksjon er inkludert, konfigurerbar, spesialtilpasset eller planlagt, og dokumenter hvert svar før den endelige poenggivningen.

Velg leverandør og varsle leverandørene

Velg leverandøren som best samsvarer med kravene, implementeringskapasiteten, budsjettet og de langsiktige driftsbehovene dine. Før du varsler noen, må du bekrefte de endelige poengsummene, tilbakemeldingene fra referanser, prisforutsetningene, kontraktsunntakene og uavklarte risikoer. Fullfør disse siste trinnene for å avslutte RFP-prosessen på en rettferdig måte og forberede teamet på implementeringen:

Varsle valgte og ikke-valgte leverandører

Kontakt den valgte leverandøren først, og informer deretter leverandører som ikke ble valgt, raskt og respektfullt. Forklar tidslinjen for beslutningen, takk hver leverandør for tilbudet, og gi begrensede tilbakemeldinger når innkjøpspolicyen din tillater det. Du kan for eksempel fortelle en leverandør som ikke ble valgt, at funksjonene for renhold fikk gode poeng, men at tidsplanen for migrering og integrasjonen med regnskapssystemet ikke oppfylte prosjektkravene.

Forbered deg til de avsluttende forhandlingene

Forhandle om punktene som påvirker kostnader, risiko og virksomhetens evne til å drifte etter lansering. Gå gjennom abonnementspriser, økninger ved fornyelse, implementeringsgebyrer, migreringstjenester, opplæringstimer, integrasjonskostnader, servicenivåmål, responstider for brukerstøtte, rettigheter til dataeksport, vilkår for oppsigelse og ansvarsbestemmelser. Be finalisten bekrefte alle endringer i et revidert tilbud og et revidert kontraktsutkast før godkjenning.

Sørg for intern enighet før signering

Innhent godkjenning fra prosjektsponsoren, økonomi- eller innkjøpsteamet, IT- og sikkerhetsansvarlige, juridiske rådgivere og avdelingsledere som berøres av implementeringen. Bekreft at det godkjente budsjettet inkluderer løpende gebyrer, engangstjenester, skatter, maskinvare, integrasjoner og kostnader til uforutsette utgifter. Gjennomfør en avsluttende gjennomgang av implementeringsplanen, ansvarsfordelingen for datamigrering, begrensninger i høysesongen og signeringsfullmakten før avtalen inngås.

Hotell-PMS-forespørselen din er klar – velg nå riktig system

Når leverandørene har svart og du har tatt valget ditt, er neste steg å sikre at PMS-systemet du har valgt, passer eiendommen din på lang sikt – veiledningen vår om  hvordan du velger et PMS-system for hotell  tar deg gjennom de viktigste kriteriene, fra kompatibilitet med integrasjoner og skalerbarhet til implementeringstype og leverandørens brukerstøtte.