Kommunicera med gäster från bokningen

Välj rätt bokning som konversationssammanhang

Öppna Gäster → Meddelanden eller gästdetaljmeddelanden. Sök på bokningsnummer, gäst, datum eller rum och verifiera sammanhangspanelen innan du skriver.

Endast bokningar kopplade till en huvudgäst kan skickas med meddelanden. Åtgärda en saknad länk i gäst- eller bokningsposten istället för att skapa en annan person.

Börja varje konversation från den exakta bokningen. Sök efter bokningsnummer, gäst- eller vistelsedatum, öppna posten och jämför mottagare, ankomst, avresa, rumskategori, aktuellt tillstånd och bokningskälla. Samma gäst kan ha flera tidigare eller framtida vistelser och en profil identifierar inte ensam vilken ankomst, avbokning eller faktura meddelandet avser. STRYK använder därför gäst och bokning tillsammans. Om bokningskontexten är otydlig, sluta innan du skriver och lös det i källposten. Behåll privata uppgifter i den auktoriserade bokningskonversationen och använd en boknings- eller rumsreferens i överlåtelseanteckningar istället för att kopiera kontaktdata någon annanstans. Kontextkontrollen är klar när en annan kollega kan identifiera den avsedda mottagaren och stanna utan att gissa från meddelandetexten.

Förstå kanalen från bokningskällan

Bokningar för manuell, telefon, walk-in, e-post, webbplats och bokningsmotor använder e-post, med ämne och vanligt eller HTML-format. Verifiera den lagrade adressen först.

OTA och kanalbokningar använder en vanlig kanalkonversation. Gå inte förbi det med ett separat e-postmeddelande, annars blir bokningshistoriken ofullständig.

Läs kommunikationskanalen från bokningskällan. Manuella och direkta bokningar använder e-post; OTA eller kanalbokningar använder bokningskanalen som en vanlig textkonversation. Kompositören tillhandahåller inte ett fritt kanalval eftersom att ändra rutten skulle bryta förhållandet mellan reservationskälla och meddelandehistorik. Bekräfta den visade kanalen och den tillgängliga mottagaren innan du väljer en mall. E-post kan använda vanlig text eller godkänd HTML med förhandsgranskning, medan kanalmeddelanden förblir ren text och inte får vara beroende av formatering som inte stöds. Om en annan kontaktväg är operativt nödvändig, behandla den som en separat auktoriserad process och dokumentera varför; dölj inte förändringen inuti kompositören. För portalbokningar skickar STRYK klartextmeddelandet via den anslutna Booking.com- eller Airbnb-rutten och behåller varje svar i samma bokningskonversation.

Välj en mall efter syfte, kanal och språk

Listan visar aktiva mallar som matchar den härledda kanalen. Välj utifrån syftet med gästresan och önskat språk, inte med ett liknande klingande namn.

STRYK tillämpar format, ämne och kropp. Återkommande korrigeringar hör hemma i den centrala mallen; engångsdetaljer stannar i utkastet. Undvik privata föråldrade kopior.

Välj en mall utifrån ett konkret syfte, den visade kanalen och gästspråket. Ankomstinformation, betalningspåminnelse, saknad data och tack efter vistelsen är olika beslut och bör inte kombineras till ett vagt universellt budskap. Använd endast en aktiv mall som erbjuds för den härledda kanalen. Läs den innan du ansöker: kontrollera hälsning, ton, hotelltider, länkar, avbokning eller betalningstext och underskrift mot gällande hotellpraxis. En mall är en granskad utgångspunkt, inte tillåtelse att skicka oförändrad. Om gästspråket skiljer sig från hotellets standard, välj eller skriv en komplett version på det språket; ett översatt ämne med blandad text är inte klart. Ta bort stycken som inte gäller denna vistelse och lägg endast till fakta som redan godkänts i boknings-, policy- eller hotellinställningar.

Granska platshållare från det verkliga bokningssammanhanget

Väljaren exponerar värden som går att lösa i det aktuella gäst- och bokningssammanhanget. Läs den lösta förhandsgranskningen och jämför datum, rum och bokningsdetaljer med kontextpanelen.

Olösta platshållare visas nedanför förhandsvisningen. Åtgärda saknade källdata, ladda om och granska igen; om den inte är tillgänglig genom design, ta bort token eller skriv om meningen.

Lös varje platshållare i förhandsgranskningen mot den aktuella bokningen. Kontrollera gästhälsning och namn, hotell, ankomst och avgång, kategori eller tilldelat rum, bokningsnummer, totalt, utestående belopp, avbokningsregler och kontaktuppgifter enligt mallens syfte. En olöst token, ett tomt streck eller ett osannolikt värde är en blockerare, inte kosmetisk text. Korrigera saknade källdata när de borde finnas; annars skriv om meningen utan att ge ett löfte. Om inget rum är tilldelat, säg den bokade kategorin istället för att gissa ett rumsnummer. Om ett betalningsvärde bestrids, byt inte ut det manuellt i meddelandet; lösa ekonomi först. Alias platshållare kan återges för kompatibilitet, men väljaren bör använda aktuella kanoniska värden som är tillgängliga i detta bokningssammanhang. Den slutliga förhandsgranskningen får endast innehålla verklig, förklarlig data.

Läs innehåll som både värd och recensent

Läs som gäst: de två första meningarna ska förklara varför hotellet skriver och vad som händer sedan. Använd tydliga tider och vardagsspråk, inte interna koder.

Granska sedan mottagare, hälsning, bokningsnummer, datum, rumsanspråk, prisreferenser, länkar, signatur och språk. HTML behöver visuell granskning; kanalmeddelanden förblir klar text.

Läs det sista meddelandet två gånger: först som värd, sedan som recensent. Som värd, gör nästa gäståtgärd uppenbar, använd ett respektfullt språk och inkludera endast information som hjälper vistelsen. Som granskare, verifiera bokningsfakta, datum, belopp, policyförklaringar, länkar, svarsdeadline, signatur och sekretess. Ett meddelande ska ha ett primärt mål och ett tydligt svar på vad gästen ska veta eller göra. Undvik intern jargong, skuld, juridiska löften som hotellet inte kan hålla och känslig information som inte krävs för ändamålet. Vid akut förändring, ange vad som ändrats, vilken vistelse som berörs och var gästen kan svara. För HTML-e-post, inspektera både formaterad förhandsgranskning och läsbar text; för kanalmeddelanden, se till att mening överlever vanlig text. Ett kortfattat specifikt meddelande är säkrare än en lång mall full av irrelevanta klausuler.

Skicka en gång och bevisa resultatet i tråden

Bekräfta bokningen, skicka en gång och vänta. Om STRYK visar ett fel, behåll utkastet, korrigera orsaken och registrera inte framgång i förtid.

Efter framgång, hitta meddelandet i samma bokningstråd och verifiera riktning, tid, kanal, ämne i förekommande fall och bokningsnummer. Om det inte är synligt, ladda om innan du försöker igen.

Skicka en gång och vänta på det faktiska resultatet. En inaktiverad knapp, spinner eller långsamt nätverk är inte tillåtet att klicka upprepade gånger. Om du lyckas öppnar du samma bokningskonversation igen och verifierar exakt en utgående post med korrekt tidsstämpel, kanal, ämne där tillämpligt och synligt innehåll. För e-post, ett framgångsrikt ansökningsresultat och trådinmatning bevisar att STRYK accepterade sändningen; leveransfel måste förbli synliga genom lämplig status eller uppföljning. För en kanalkonversation, bekräfta att vanligt textmeddelande finns i rätt reservationstråd. Om sändningen misslyckas, bevara utkastet, läs felet och korrigera mottagare, kanal, innehåll eller anslutning vid dess källa. Skapa aldrig en lokal framgångspost eller kopiera meddelandet till en annan bokning bara för att få historiken att verka komplett.

Kontrollera två vanliga misstag med ett separat test. Första fallet: gästen har ingen användbar e-postadress i en direktbokning. Det korrekta resultatet är att inte gissa mottagaren eller använda en annan gästs adress, utan synlig blockering och förtydligande av kontaktuppgifterna i gästprofilen eller bokningen. Andra fallet: De skulle välja en e-postmall för OTA-bokning. Kanalen och den vanliga textformen som härleds av systemet bör förbli synliga; kopiera inte meddelandet manuellt till ett separat e-postmeddelande genom att tappa konversationsanslutningen. För båda repetitionerna, skriv ner bokningsnummer, förväntad kanal, faktisk feedback och nästa ansvarig. På så sätt kan teamet inte bara hantera framgångsrika sändningar, utan också säkert stoppa när källdata eller kanal inte är lämplig.

Upprätthåll en standard för teammeddelanden

Definiera en ansvarig mall per återkommande situation, kanal och språk, med ägarskap och regelbunden granskning. Föredrar ett litet tydligt set framför många liknande namn.

Hotel Nordlicht testar direkt vanlig e-post, direkt HTML-förhandsvisning, OTA vanlig kanal, en saknad platshållare och en gäst med två bokningar. Problem åtgärdas på käll-, mall- eller bokningsnivå.

Upprätthåll en liten teamstandard för återkommande meddelanden. Varje godkänd mall behöver syfte, kanal, språk, ägare, datum för senaste granskning och nästa recensionsutlösare. Granska efter ändringar av incheckningstider, betalningsprocess, avbokningsregler, hotellkontakt, länkar eller gästresa. Behåll mallinnehåll i den centrala STRYK-katalogen och platshållare i det centrala mallsystemet snarare än personliga utdrag eller lokala filer. Prova en riktig konversation efter aktivering i den isolerade Hotel Nordlicht-demon, kontrollera bokningssammanhang, lösta värden, redaktionell kvalitet och enkelsändning; använd aldrig en befintlig kundhyresgäst för dokumentation. Ta bort föråldrade mallar istället för att lämna nästan dubbletter aktiva. Processen är tillförlitlig när en kollega senare kan förstå syfte, mottagare, vistelse, kanal, exakt innehåll och resultat enbart från bokningskonversationen.

Ta prov på minst tre konversationer per månad eller efter varje betydande operativ förändring: ett direkt e-postmeddelande, en kanal med vanlig textmeddelande och ett fall där sändningen måste blockeras. Kontrollera rätt bokningskontakt, gästspråk, olåst platshållare, tydligt mål, engångsutgående linje och ansvarsfull stängning av felet. Kopiera inte personligt innehåll till ett utbildningsdokument; kvalitetskontroll bör endast registrera den erforderliga bokningsreferensen och resultatet. I händelse av ett återkommande fel, korrigera inte varje meddelande ett efter ett: identifiera om det orsakas av en mall, central hotelldata, bokningskälla eller teamprocess, beställ en korrigering och ett nytt test.

Anteckna datum och person som ansvarar för granskningen bredvid mallen så att anledning och förfallodatum för nästa granskning är tydligt för alla kollegor.