Sådan skriver du en udbudsanmodning for hoteladministrationssoftware

At skrive en RFP for ejendomsadministrationssoftware til hoteller er et af de klogeste skridt, du kan tage, før du forpligter dig til et nyt system. En anmodning om forslag (RFP) er et formelt dokument, du sender til leverandører, hvor du beder dem svare på dine specifikke krav, spørgsmål og kriterier.

Brug en RFP, når du evaluerer flere leverandører og har brug for strukturerede, sammenlignelige svar – ikke salgsmateriale.

En velskrevet RFP tvinger leverandørerne til at forholde sig til dine faktiske behov i stedet for at præsentere deres standarddemonstration. Den skaber ansvarlighed hos begge parter og giver dit team en ensartet ramme for evalueringen. Resultatet er en liste over kandidater baseret på fakta, ikke indtryk.

Har du faktisk brug for en RFP?

En RFP er ikke altid det rigtige værktøj – men når du skal træffe en vigtig softwarebeslutning, er den ofte det bedste valg. For ejendomsadministrationssoftware til hoteller giver processen størst udbytte, når din evaluering indebærer reel kompleksitet eller organisatorisk ansvarlighed. En RFP giver mening i situationer som disse:

• Du evaluerer tre eller flere leverandører på samme tid.
• Din ejendom har flere afdelinger, lokationer eller integrationskrav.
• En indkøbskomité eller ejergruppe har brug for dokumenteret begrundelse.
• Du udskifter et eksisterende system, hvor der indgår betydelig datamigrering.
• Budgetgodkendelse kræver en formel konkurrencebaseret tilbudsproces.

Hvornår kan en RFP være unødvendig?

Hvis du har en lille, uafhængig ejendom med enkle behov og en liste over en eller to leverandører, som du allerede har tillid til, vil en struktureret leverandørdemonstration og en klar liste med spørgsmål sandsynligvis føre dig i mål. Spring RFP'en over, når hurtighed er vigtigere end processen, og din beslutning ikke kræver ekstern godkendelse.

RFI vs. RFP vs. RFQ: Hvad er forskellen?

En RFI indsamler oplysninger, en RFP anmoder om løsningsforslag, og en RFQ beder om specifikke priser. Ikke alle køb af ejendomsadministrationssoftware til hoteller kræver en RFP, især ikke når dine krav og den foretrukne løsning allerede er klare. Ved at vælge det rigtige dokument får leverandørerne den rette retning, og dit team kan sammenligne svarene på en fair måde.

Brug denne tabel til at matche hvert indkøbsdokument med dine behov for softwareindkøb:

Almindelige RFP-fejl, du bør undgå

Svage RFP'er efterlader leverandørerne i tvivl om din ejendom, dine prioriteter og dine indkøbsbegrænsninger. Det kan føre til vage svar, uensartede priser og forslag, der er vanskelige at sammenligne. Almindelige fejl omfatter brede krav, uklare ansvarsområder, manglende fokus på implementeringsbehov og manglende specifikation af, hvordan leverandørerne skal forklare begrænsninger eller ekstra omkostninger.

Undgå disse fejl for at gøre leverandørernes svar mere nyttige og sammenlignelige:

Utilstrækkelig baggrund eller kontekst

Forklar din ejendomstype, antal værelser, placeringer, afdelinger, nuværende system og projektmål. Uden denne kontekst kan leverandører foreslå uhensigtsmæssige konfigurationer eller overse krav som rapportering på tværs af flere ejendomme, arbejdsgange for rengøring eller behov for migrering. Inkluder en kort ejendomsprofil, og beskriv de driftsproblemer, som det nye system skal løse.

Manglende eller uklart budget

Angiv dit forventede budgetinterval, eller bed om en fuldstændig opdeling af engangs- og tilbagevendende omkostninger. Uden tydelige prisretningslinjer kan leverandører foreslå løsninger, der overstiger din godkendelsesgrænse, eller udelade omkostninger til implementering, integrationer, oplæring, support og datamigrering. Bed leverandørerne om at adskille hver omkostning og identificere valgfrie gebyrer.

Vage krav eller juridisk jargon

Skriv kravene i et klart og enkelt sprog, og beskriv det resultat, som dit team har brug for fra hver funktion. Vage formuleringer skaber forskellige fortolkninger, mens et overdrevent juridisk sprog kan skjule vigtige driftsdetaljer. Brug konkrete spørgsmål, f.eks. hvordan systemet håndterer værelsestildelinger, prisbegrænsninger, revisionsspor og adgang til gæstedata.

Evalueringskriterier er ikke delt

Fortæl leverandørerne, hvordan du vil vurdere forslagene, før de svarer. Uden fælles kriterier kan leverandørerne fokusere på deres foretrukne salgsargumenter, og dit team kan bedømme svarene inkonsekvent. Tildel vægte til områder som funktionalitet, integrationer, implementering, support, sikkerhed, brugervenlighed og samlede omkostninger.

Intet standardformat for leverandørernes svar

Giv alle leverandører den samme svarskabelon, rækkefølge af spørgsmål og prisstruktur. Ustrukturerede forslag gør det sværere at sammenligne inkluderede funktioner, forudsætninger, serviceniveauer, kontraktvilkår og undtagelser. Kræv, at leverandørerne besvarer hvert krav direkte og mærker svarene som inkluderet, konfigurerbart, tilpasset, ikke tilgængeligt eller kræver afklaring.

Join our Community

Keep up with the hotel management community!

Get Free Access

Have an account? Log In

Sammensæt dit RFP-team til hoteladministrationssoftware

Et tværfunktionelt team hjælper dig med at kortlægge driftsbehov, indkøbsbegrænsninger og tekniske krav, før leverandørerne indsender deres forslag. Det skaber også et fælles ejerskab, så den endelige beslutning afspejler, hvordan ejendommen rent faktisk fungerer.

Inddrag disse grupper for at udarbejde et praktisk RFP og gennemgå leverandørernes svar retfærdigt:

Projektsponsor

Hotelchefen, ejeren, driftsdirektøren eller den regionale driftsdirektør kan være sponsor for RFP'et om hoteladministrationssoftware. Denne person fastlægger projektets prioriteter, bekræfter budgetforventninger, løser modstridende krav og giver den endelige godkendelse.

Funktionelle eksperter

Receptionschefen, chefen for værelsesafdelingen, indtægtschefen, rengøringschefen, den økonomiansvarlige og IT-chefen kan definere afdelingernes krav. De bør forklare de nuværende arbejdsgange, identificere integrationsbehov, gøre opmærksom på mangler i rapporteringen og vurdere, om de foreslåede funktioner understøtter den daglige drift.

Indkøbsansvarlige eller RFP-forfattere

En indkøbschef, indkøbsspecialist, projektleder eller forretningsanalytiker kan organisere RFP-processen. Denne gruppe udarbejder svarskabelonen, fastsætter frister, standardiserer prisforespørgsler, dokumenterer forudsætninger og koordinerer leverandørernes spørgsmål.

Slutbrugere og interessenter

Receptionister, reservationsmedarbejdere, rengøringspersonale, nattevagter, ejendomsrevisorer og ejerrepræsentanter kan beskrive praktiske behov og betænkeligheder i forbindelse med beslutningen. Deres feedback hjælper med at teste brugervenligheden, identificere oplæringsbehov, vurdere adgangstilladelser og bekræfte, at forslagene passer til de faktiske arbejdsgange for gæsteservice.

Definer ufravigelige krav & mål

Definer, hvad din nye hoteladministrationssoftware skal kunne, før du beder leverandørerne om forslag. Tydelige problemområder, mål og ufravigelige krav hjælper leverandørerne med at målrette deres svar til din drift og gør dem lettere at sammenligne.

Brug disse områder til at definere jeres krav:

• Aktuelle problemer med systemet: Beskriv, hvor jeres nuværende system skaber forsinkelser, fejl eller dobbeltarbejde. Forklar for eksempel, om receptionister indtaster bookingoplysninger igen, om rengøringspersonalet mangler opdateringer om værelsesstatus i realtid, eller om ledere eksporterer rapporter manuelt.

• Nødvendige forbedringer og resultater: Knyt hver ønsket funktion til et målbart driftsresultat. I kan have behov for hurtigere indtjekningsarbejdsgange, færre uoverensstemmelser i værelsesstatus, mere nøjagtige belægningsrapporter eller bedre indsigt i vedligeholdelsesopgaver.

• Funktionelle, tekniske og lovgivningsmæssige behov: Oplist nødvendige funktioner inden for reservationer, fakturering, rengøring, rapportering, integrationer med regnskabssoftware til hoteller, sikkerhed og databeskyttelse. Angiv krav såsom betalingsbehandling, regnskabsintegration, rollebaseret adgang, revisionslogge, dataopbevaring og overholdelse af gældende databeskyttelsesforpligtelser.

• Brugerroller, brugsniveauer og arbejdsgange: Identificer alle brugergrupper, det forventede antal brugere, adgangsniveau og de vigtigste arbejdsgange. Medtag receptionister, nattevagter, rengøringspersonale, indtægtsansvarlige, økonomimedarbejdere og regionale driftsansvarlige samt spidsbelastning under ankomster eller vagtskifte.

• Præferencer for implementering: Angiv, om I foretrækker en cloudbaseret, lokalt hostet eller hybrid implementering. Forklar krav til browseradgang, mobile arbejdsgange, modstandsdygtighed over for internetudfald, konfiguration på ejendomsniveau, opdateringer, datahosting og leverandøradministreret infrastruktur.

Skriv RFP'en for hotellets ejendomsadministrationssoftware

Når jeres mål, krav og interessenter er defineret, er næste skridt at omsætte dem til en fokuseret RFP. Et velorganiseret dokument giver leverandørerne en klar retning og hjælper jeres team med at sammenligne funktionalitet, implementeringsplaner, priser og support. Medtag disse afsnit i jeres RFP:

1. Ledelsesresume

Beskriv jeres ejendom, projektmål, nuværende system og årsagen til, at I søger ny software. Nævn oplysninger såsom antal værelser, ejendomstype, antal lokationer og den planlagte beslutningsdato. Forklar de resultater, I forventer, såsom én reservationspost på tværs af afdelinger eller bedre indsigt i værelsesstatus.

2. Arbejdsomfang

Definer de tjenester og softwarefunktioner, som leverandørerne skal levere. Medtag reservationer, reception, rengøring, vedligeholdelse, fakturering, rapportering, integrationer, migrering, support og administration af flere ejendomme, hvor det er relevant. Bed for eksempel leverandørerne forklare, hvordan deres system håndterer værelsesflytninger, gruppebookinger, delte betalinger og værelser, der er ude af drift.

3. Tekniske krav

Oplist de tekniske betingelser, som jeres team forventer, at platformen opfylder. Dæk implementeringsmodel, understøttede browsere og enheder, mobiladgang, API'er, integrationer, dataeksport, mål for oppetid, sikkerhedskopieringsprocesser og ydeevne under spidsbelastning ved ankomster. Angiv eksisterende systemer såsom regnskabs-, betalings- og kassesystemer, hotelbookingsmotor, kanaladministration eller platforme til identitetsstyring.

4. Leverandørkvalifikationer

Bed leverandørerne fremlægge dokumentation for, at de kan understøtte ejendomme, der ligner jeres. Anmod om virksomhedshistorik, kunder inden for hotelbranchen, relevant implementeringserfaring, supportlokationer, økonomiske oplysninger og referencer. Spørg referencerne om migreringsnøjagtighed, svartider, systemtilgængelighed, kvaliteten af oplæringen og hvordan leverandøren håndterede uløste problemer.

5. Krav til sikkerhed og overholdelse

Angiv jeres krav til beskyttelse af gæste-, betalings-, medarbejder- og virksomhedsdata. Bed leverandørerne beskrive adgangskontroller, multifaktorgodkendelse, kryptering, revisionslogge, sårbarhedstest, håndtering af hændelser, dataopbevaring og underleverandører. Inkludér relevante forpligtelser, såsom krav til betalingskort og databeskyttelseslovgivning, der påvirker jeres gæster eller driftssteder.

6. Forventninger til implementering og oplæring

Beskriv de implementeringstjenester, I har brug for, herunder afdækning, konfiguration, datamigrering, integrationstest, brugergodkendelsestest, support ved lancering og gennemgang efter lanceringen. Fastlæg forventninger til projektmilepæle, leverandøransvar, ejendomsansvar og eskaleringsprocedurer. Bed leverandørerne fremlægge en oplæringsplan for receptionister, natrevisorer, rengøringsteams, ledere og administratorer.

7. Prissætning og licensering

Kræv, at leverandørerne opdeler abonnementsgebyrer, oprettelsesomkostninger, implementeringstjenester, integrationer, migrering, oplæring, support, hardware, skatter og valgfrie moduler. Definér prisgrundlaget, f.eks. værelser, ejendomme, brugere, transaktioner eller forbrugsniveauer. Bed om samlede priser for tre eller fem år, prisstigninger ved fornyelse, minimumsforpligtelser og gebyrer for tilføjelse af værelser eller lokationer.

8. Kontraktvilkår

Specificér de kommercielle og juridiske vilkår, som jeres organisation forventer, at leverandørerne forholder sig til. Dæk kontraktlængde, fornyelser, opsigelsesrettigheder, serviceniveauer, svartider for support, dataejerskab, dataeksport, fortrolighed, ansvar, forsikring, prisændringer og underleverandører. Bed leverandørerne identificere undtagelser fra jeres vilkår og fremlægge en version med ændringer markeret af enhver foreslået aftale.

9. Krav til leverandørernes svar

Bed leverandørerne strukturere deres svar i et ensartet format, så jeres team lettere kan sammenligne forslagene. Kræv, at de forholder sig til hvert funktionelt krav, angiver, om funktionerne er standard, konfigurerbare, specialudviklede eller ikke tilgængelige, og forklarer eventuelle afhængigheder, begrænsninger eller yderligere omkostninger. I kan også bede leverandørerne angive, hvor tredjepartsintegrationer eller implementeringstjenester er nødvendige.

Definér jeres evalueringskriterier

Fastlæg jeres evalueringskriterier, før leverandørerne indsender forslag, især når flere afdelinger skal gennemgå forskellige funktioner. Beslut, hvilke faktorer der er vigtigst—såsom funktionalitet, brugervenlighed, integrationer, implementering, support og samlede omkostninger—og tildel hver faktor en vægt baseret på dens betydning. Ved at bruge den samme vægtede vurderingsramme for hvert forslag kan jeres team evaluere leverandørerne ensartet og sikre, at beslutningerne er knyttet til de operationelle prioriteter.

Hvad er vigtigst?

Vælg tre til fem vægtede kategorier, der afspejler jeres projektmål og driftsprioriteter. En koncern med flere ejendomme kan f.eks. lægge større vægt på rapportering og central administration, mens et selvstændigt hotel kan prioritere arbejdsgange i receptionen og implementeringssupport. Overvej disse almindelige vurderingskategorier, og vælg derefter kun dem, der er vigtigst for jeres team:

• Funktionelt match
• Integrationsmuligheder
• Implementeringsplan
• Brugeroplevelse
• Rapportering og analyse
• Sikkerhed og overholdelse af regler
• Support og oplæring
• Samlede omkostninger
• Leverandørens erfaring
• Kontraktvilkår

Brug en vurderingsmatrix

Opret en vurderingsmatrix med én række for hvert kriterium og én kolonne for hver leverandør. I kan f.eks. tildele funktionelt match 30 %, integrationer 20 %, implementering 15 %, support 15 %, sikkerhed 10 % og samlede omkostninger 10 % og derefter justere vægtene efter jeres egne prioriteter. Få bedømmerne til at vurdere hvert kriterium på en ensartet skala fra 1–5 eller 1–10, og gang hver vurdering med den tildelte vægt. Hvis migreringsrisiko er jeres største bekymring, skal I øge vægten for implementering i stedet for at lade alle kategorier tælle lige meget.

Afklar jeres vurderingsproces

Definér, hvem der skal vurdere forslagene, og hvilke beviser bedømmerne bør tage i betragtning, før svarene ankommer. Inkludér repræsentanter fra receptionen, rengøring, økonomi, IT, indtægtsstyring og ejerskabet, når deres ansvarsområder påvirker købet. Brug en standardiseret vurderingsskala med beskrivelser af hver vurdering, og planlæg derefter et kort afstemningsmøde, så bedømmerne fortolker kravene ensartet, før vurderingen begynder. Kræv skriftlige kommentarer ved usædvanligt høje eller lave vurderinger, f.eks. ved en manglende økonomiintegration eller en uklar oplæringsplan.

Udsend RFP'et om hoteladministrationssoftware

Distribuér dit RFP gennem en tydelig og kontrolleret proces, så alle leverandører modtager de samme oplysninger og har lige lang tid til at svare. En ensartet proces giver også dit team en pålidelig oversigt over spørgsmål, frister og indsendelser; brug disse fremgangsmåder:

Vælg den rette distributionsmetode

Send RFP'et direkte via e-mail, offentliggør det gennem en indkøbsportal, eller invitér leverandører via en centraliseret platform til indhentning af tilbud. Ved de fleste søgninger efter hotelsoftware anbefaler jeg et centraliseret system, der registrerer dokumentadgang, leverandørspørgsmål, modtagelse af tilbud og revisionshistorik på ét sted. Medtag en kontaktliste over leverandører, eller brug en rollebaseret indbakke, f.eks. pms-rfp@yourhotel.com, så kommunikationen forbliver tydelig, når flere teammedlemmer administrerer processen.

Fastlæg tydelige forventninger til tidsplanen

Offentliggør alle milepæle i selve RFP'et, herunder tidszonen og om datoerne henviser til kalenderdage eller arbejdsdage. En praktisk tidsplan for en søgning efter hoteladministrationssoftware kunne se sådan ud:

• Udsendelsesdato for RFP: Send det endelige dokument og svarskabelonen til alle inviterede leverandører.
• Periode for leverandørspørgsmål og svar: Afsæt fem til syv arbejdsdage til spørgsmål, og del derefter svarene med alle deltagende leverandører.
• Frist for endelig indsendelse: Giv leverandørerne to til tre uger til at udarbejde deres tilbud, efter de har modtaget RFP'et.
• Evaluerings- og udvælgelsesperiode: Afsæt en til to uger til bedømmelse, demonstrationer, referencekontrol og udvælgelse af finalister.

Underret leverandørerne hurtigt, hvis en milepæl ændres, og giv alle deltagende leverandører en eventuel forlængelse på samme tid.

Fastlæg kravene til indsendelse

Fortæl leverandørerne præcis, hvordan tilbuddene skal indsendes, f.eks. PDF til den skriftlige besvarelse, XLSX til priser og DOCX til udfyldte spørgeskemaer. Angiv leveringsmetoden, f.eks. en indkøbsportal, et sikkert uploadlink eller en rollebaseret indbakke, og oplys, om leverandørerne skal bruge dine skabeloner eller formularer. Forklar også tidszonen for fristen, tilbuddets gyldighedsperiode, grænser for filstørrelse, navngivningskonventionen samt om forsinkede indsendelser vil blive afvist eller kun accepteret med skriftlig godkendelse.

Evaluer og udvælg leverandørernes svar

Gennemgå hvert tilbud i forhold til de krav og den evalueringsramme, du fastlagde tidligere. Sammenlign dokumenterede funktioner, prisforudsætninger, tidsplaner for implementering, supportforpligtelser og eventuelle undtagelser, som leverandørerne har identificeret. Brug resultaterne til at indsnævre feltet til de leverandører, der fortjener en mere grundig validering gennem demonstrationer, referencekontrol eller opfølgende spørgsmål:

• Standardisér gennemgangen af tilbuddene: Omsæt hvert svar til det samme regneark eller den samme sammenligningstabel. Registrér, om hvert krav er inkluderet, kan konfigureres, kræver specialtilpasning, ikke er tilgængeligt eller er uklart, og notér forudsætninger om integrationer, antal brugere og support.

• Brug en vægtet bedømmelsesmatrix: Bedøm funktionelt match, integrationer, implementering, support, sikkerhed, brugervenlighed og samlede omkostninger ved hjælp af aftalte vægte. Giv f.eks. migration og oplæring større vægt, når et system skal udskiftes før højsæsonen.

• Planlæg strukturerede demonstrationer: Giv hver finalist identiske scenarier i stedet for at tillade generiske præsentationer. Bed leverandørerne demonstrere et værelsesskift, delt betaling, gruppebooking, opdatering af rengøringsstatus, natrevision og eksport til regnskab ved hjælp af dine arbejdsgange.

• Interview leverandørernes referencer: Tal med hoteller, der har et tilsvarende antal værelser, ejendomstyper, integrationer eller behov på tværs af flere ejendomme. Spørg referencerne om migrationsnøjagtighed, svartider fra supporten, kvaliteten af oplæringen, systemtilgængelighed og uløste implementeringsproblemer.

• Afklar mangler i tilbuddene: Send skriftlige spørgsmål, når priser, funktionalitet, tidsplaner eller kontraktvilkår virker uklare. Spørg, om en ønsket funktion er inkluderet, kan konfigureres, kræver specialtilpasning eller er planlagt, og dokumentér hvert svar før den endelige bedømmelse.

Vælg og underret leverandørerne

Vælg den leverandør, der bedst matcher dine krav, implementeringskapacitet, budget og langsigtede driftsbehov. Før du underretter nogen, skal du bekræfte de endelige bedømmelser, feedback fra referencer, prisforudsætninger, kontraktundtagelser og uafklarede risici. Gennemfør disse sidste trin for at afslutte RFP-processen på en fair måde og forberede dit team på implementeringen:

Underret udvalgte og ikke-udvalgte leverandører

Kontakt først den valgte leverandør, og underret derefter de ikke-valgte leverandører hurtigt og respektfuldt. Forklar tidsplanen for beslutningen, tak hver leverandør for tilbuddet, og giv begrænset feedback, når din indkøbspolitik tillader det. Fortæl for eksempel en ikke-valgt leverandør, at funktionerne til rengøringsadministration scorede godt, men at tidsplanen for migreringen og integrationen med regnskabssystemet ikke opfyldte projektkravene.

Forbered de endelige forhandlinger

Forhandl om de forhold, der påvirker omkostninger, risiko og din ejendoms evne til at fungere efter lanceringen. Gennemgå abonnementspriser, prisstigninger ved fornyelse, implementeringsgebyrer, migreringstjenester, antal undervisningstimer, integrationsgebyrer, servicemålsætninger, svartider for support, rettigheder til dataeksport, opsigelsesvilkår og bestemmelser om ansvar. Bed finalisten om at bekræfte alle ændringer i et revideret tilbud og et revideret kontraktudkast, før det godkendes.

Sikr intern enighed før underskrivelse

Indhent godkendelse fra projektsponsoren, økonomi- eller indkøbsteamet, de ansvarlige for IT og sikkerhed, den juridiske rådgiver samt de afdelingsledere, der påvirkes af implementeringen. Bekræft, at det godkendte budget omfatter tilbagevendende gebyrer, engangsydelser, skatter, hardware, integrationer og uforudsete omkostninger. Foretag en afsluttende gennemgang af implementeringsplanen, ansvarsområderne for datamigrering, begrænsninger i højsæsonen og underskriftsbeføjelserne, før aftalen indgås.

Din RFP for hotel-PMS'et er klar – vælg nu det rigtige system

Når leverandørerne har svaret, og du har truffet dit valg, er næste skridt at sikre, at det PMS, du har valgt, er den rigtige langsigtede løsning for din ejendom – vores guide om  hvordan du vælger et PMS til hotellet  gennemgår de vigtigste kriterier, fra kompatibilitet med integrationer og skalerbarhed til implementeringstype og leverandørsupport.