Set up Website & Booking Engine end to end

Understand the Website studio and its ownership model

Open Website from the main navigation. Its fixed header shows publication state and the public property address. The preview icon opens the current authenticated draft in a new tab without publishing or creating a booking. Publish creates a new live snapshot only after readiness has passed and an explicit confirmation. When a version is live, Reset to draft takes the public site offline after another confirmation while preserving both the editable draft and previous snapshot history.

Design & Layout selects the template, room presentation and page composition shared by guest-facing surfaces. Booking Page contains page copy, public navigation, booking rules, guest portal and website snippets. Online Check-in controls invitations, timing, required data, consent, signature and reception review. Check-in Kiosk controls the arrival screen on a managed tablet. Vouchers contains shop, products, values, online payments readiness, orders and its embed. Emails brings together editable booking, check-in and voucher message content.

Property name, logo, colours, font and public slug are deliberately maintained under Settings → Property. Payment providers and technical checkout readiness belong to central payment or integration settings; mail servers and senders belong to communication settings. Rooms, categories, photos, capacity, rates, prices, availability, extras, amenities, cancellation policies, finance and privacy also remain in their owning modules. The Website studio links to and consumes those sources instead of creating another copy.

Within each visual area, work in either Preview or Configuration. Preview uses the same shared React renderer as the guest site and provides device, refresh, zoom and full-screen controls. Configuration autosaves routine changes to draft after a short pause and exposes loading, saving, success and failure. A saved draft is not live. After every material change, review the affected language, device size and guest journey before publishing again.

Approve central product sources before the studio

Start in Rooms & categories with names, occupancy, physical inventory, real photos and multilingual descriptions. Availability comes from real inventory.

At least one active direct rate plan must return a valid STRYK price. Public booking never trusts a client-invented total or fallback rate.

Brand and domain live in Property settings; policies, amenities and extras remain in their central modules. Guest-facing email copy belongs to Website → Emails. Booking Page selects and orders rather than copying.

Treat this preparation as a source-of-truth audit, not as page decoration. Record which room category supplies each offer, which physical rooms create its inventory, which Direct rate plan calculates the price and which policy governs cancellation. Then verify the same chain for a normal date, a sold-out date and a blocked room. If a room is deactivated or blocked, the public quantity must fall automatically. If a plan has no valid price, the offer must disappear rather than show an estimate. This short audit prevents the most expensive launch error: a polished page that sells a product the hotel cannot deliver.

Configure design, booking page, languages and booking mode

Open Website → Design & Layout. Choose one of five production templates by property type, imagery and desired information density: Classic Hotel balances media, search and offer; Alpine Retreat is immersive and image-led; Urban Boutique is typographic and compact; Luxury Calm gives imagery and calm spacing more room; Compact Direct puts availability first. Every template uses the same real availability, pricing, multi-room, extras, payment and booking logic. Template choice changes composition, not data source or professional behaviour.

Set room-card presentation, spacing and other layout rules, and open central corporate design through the Settings → Property deep link when needed. Logo, primary and accent colours, font and corner style apply across booking page, guest portal, online check-in, kiosk, voucher shop and guest email. Custom CSS remains a closed expert area: scope it to the intended Website container, verify it on mobile and review it again after every template change. Never use CSS to hide functional controls, prices, policies or validation states.

Move to Website → Booking Page and complete page title, action copy, property description, navigation and trust content for every active guest language. STRYK supports 18 guest languages. Maintain room names, short and full descriptions and amenities centrally under Rooms & categories; STRYK can draft a translation from the property default language into an enabled secondary language there. Review and correct every AI draft before saving, especially prices, proper names, services and legally relevant statements. Then review the complete journey including availability calendar, alternative dates, multi-room search, rooms, plans, extras, guest details, policies, voucher entry, payment and summary. No guest may encounter empty copy, incorrect terms or incomplete room information after changing language.

Set operating rules and choose request, auto-confirm or payment-required deliberately. Payment-required needs a verified checkout-capable provider, not a visual placeholder.

Publish only complete categories, direct plans, extras, public policies and active amenities. Ordering changes presentation, not source truth.

Before moving on, write down the intended booking mode and test it against the hotel operation. Request mode needs a clear response responsibility and deadline. Automatic confirmation needs dependable inventory and a complete confirmation message. Payment required additionally needs a public payment method and a provider connection that can really complete checkout. For every active guest language, review the hero title, action text, hotel description, room content, policy and confirmation message as one journey. A translated menu is not multilingual readiness when the decisive sales or legal content remains empty. Confirm that every published extra has a clear unit, price and fulfilment owner at the hotel.

Configure online check-in and guest portal safely

Enable online check-in only after guest languages, property times and required data are agreed. Define how many hours before arrival an invitation becomes due, how long its secure link remains valid and whether passport details, explicit consent and a handwritten signature are required. The exact consent and signature declarations shown at submission are retained with language, version and time as evidence. Enable manual front-desk review whenever submitted information must not become approved automatically.

For automatic invitations, deliberately select eligible booking channels, booking types and guest segments. STRYK selects due direct or manually entered bookings in property time and sends each secure link at most once. Booking.com, Expedia and Airbnb remain in their actual OTA communication channel; this email automation never impersonates an OTA message. Review evidence for pending, sent, skipped or manual-review outcomes. An ambiguous SMTP result is not retried blindly.

The reception worklist separates submitted, in review, correction required and approved. An authorised operator claims the review, compares booking, guest details, companions, document data, consent and signature, and requests a specific correction where needed. Approved online check-in prepares arrival; it does not by itself replace physical room check-in, room readiness or a required authority-registration transmission. Those remain separate, traceable operating states.

Enable the optional guest portal under Booking Page and deliberately choose between a secure booking link without a persistent account and an additional guest account; when disabled it stays completely hidden. Guests receive time-limited access through designated booking emails or request it through a verified email address. They see only eligible bookings, stay details, payment state and cancellation policy. An eligible direct or manually entered booking is cancelled idempotently in the PMS. Booking.com, Expedia, Airbnb and other OTA bookings remain with their source channel and cannot be cancelled in parallel through the STRYK portal. Requests about dates, occupancy or contact details enter the reception queue; front desk still changes price, room and stay through the canonical booking workflow.

Set up the check-in kiosk as a managed workstation

Enable kiosk only on a dedicated tablet or front-desk terminal. STRYK provisions one property-specific user following kiosk-[property-slug]. Set a strong separate password and never use an owner or reception account on the device. A kiosk-role login opens the kiosk application directly rather than normal STRYK administration. If the kiosk is retired or a device is lost, delete the kiosk user or change its password immediately so existing sessions are invalidated.

Maintain a concise welcome title and instruction in the intended default language. Set inactivity timeout short enough that the previous guest’s information does not remain on screen. Show reception guidance helps guests without a booking number; it explicitly does not create a walk-in booking at the kiosk. Also choose whether successful check-in shows only confirmation, the room number, a key-safe code or a custom message. Expose room or safe details only when room release and key operations are designed for it.

Use kiosk preview to verify wording, language, timeout guidance and completion action. Then run a controlled eligible booking on the intended device. Test lookup, identity match, required check-in data, consent, signature, room state and completion screen. Restrict browser navigation, password storage, notification previews and other applications according to the property’s device policy. Clean up through normal booking and check-in operations; never alter a real guest booking merely for a layout test.

Connect email, vouchers, domain and snippets

Under Emails, edit only the subject and property copy for supported booking, online-check-in and voucher messages in every active guest language. STRYK’s HTML shell, logo, colours and font come from the property design. Booking, portal, check-in and voucher URLs, access tokens, security logic and PDF attachments are inserted in STRYK and cannot be removed or replaced with unsafe links in the normal editor. Changes autosave as draft and must be reviewed with representative data in both text and HTML rendering.

Treat delivery state as evidence rather than decoration. Distinguish pending, sending, accepted by the mail STRYK, failed and manual review. For an ambiguous outcome, inspect recipient, property mailbox and event history before choosing a deliberate resend. Technical acceptance does not prove that the guest read the message. Secure links must therefore be reissued only through the intended authenticated support flow.

Under Vouchers, configure the public voucher shop, fixed products, optional custom-value limits, validity and terms. Online selling is enabled only with an active Website domain, verified email delivery and a fully connected online payments live account. After confirmed capture, STRYK creates exactly one order, voucher, immutable PDF, secure digital access and delivery request. Orders and ambiguous delivery outcomes remain visible in the studio. Cash issuance, QR validation, partial or full redemption and finance correction are covered in the dedicated Set up, sell and redeem hotel gift vouchers guide.

The standard public address is {property-slug}.staystryk.com. Check and save the slug under Settings → Property → Domain; normal changes are limited to two per calendar year because guest address and standard sender must remain operationally stable. Website studio always shows the active address. A custom property domain additionally requires the supported DNS and verification process and must not be treated as public before activation is confirmed. Do not create an ad-hoc redirect or web-STRYK exception as a substitute.

Under Booking Page → Snippets, first register each property website as an exact HTTPS origin; paths, wildcards and insecure HTTP addresses are rejected. Only after a successful publication and active domain does STRYK generate origin-bound code. Available forms include the booking URL, simple booking button, compact CTA, availability widget, booking body, available rooms and the full iframe page. A compact availability widget is usually the right homepage entry, with completion continuing on the full booking page. Test embedding, mobile height, keyboard focus, cookie behaviour and Content Security Policy on the real property website.

Close all eleven readiness checks

Readiness has eleven checks. A high percentage is not enough if payment or confirmation remains missing.

Use each deep link to fix the source, return to Website and refresh. Do not hide missing inventory, photos or rates with cosmetic content.

A green check proves presence, not content quality. Review images, plans, policies and payment commercially and operationally.

Use the eleven checks as a signed launch sheet. Confirm an active subdomain; template and primary colour; basic configuration; hero, action text and hotel description in every active language; at least one bookable category backed by physical inventory; a genuine room photo; an active Direct rate plan; a usable public payment method; a checkout-capable connection when payment is required; a public cancellation policy; and an active confirmation email with subject and body in every language. Add the reviewer and date beside every item. A green system result proves that data exists. The named reviewer proves that the data is correct, understandable and commercially suitable for this hotel.

Systematically approve the internal draft preview

Use only Website → Booking Page preview at /booking/preview/draft for unpublished work. It uses authenticated preview data, creates no booking and is not proof of a live public domain.

Start at mobile width, then desktop, and repeat every language. Check no clipping, overlap, broken focus or wrong brand.

Test available, unavailable and price-boundary searches. Validate inventory, plans, nightly prices, extras, total, guest counts and validation.

Keep a small preview matrix with device, language and scenario. At minimum, run mobile and desktop for every active language, then cover one normal stay, one unavailable or blocked period and one pricing boundary. Follow the complete path from search through category, rate plan, extras, guest data, policy acceptance and summary. Note the expected result before testing, then record the observed result and a screenshot reference. The draft preview is deliberately safe: it reads authenticated draft availability and pricing but creates no reservation. Therefore it proves layout, wording, validation and calculation flow; it does not prove that the public hostname, outgoing email or live booking creation works.

Understand publish as a versioned live state

On publish, the STRYK rechecks readiness and stores a versioned snapshot with time and operator. Open blockers reject publication.

Public config is served only for live plus active domain. Ready is not public, and later draft changes do not silently replace the snapshot.

After success, open the active domain and verify hostname, HTTPS, language and version. Snippets require live plus active domain; do not invent external scripts.

Publication is an approval event, not a save button. The STRYK repeats readiness and rejects the request if a mandatory condition changed after the last review. A successful publication records a version, timestamp, operator and complete approved snapshot. Public delivery then requires both live status and an active domain; the intermediate ready state is never public. Later edits remain in the draft until another review and publication replaces the snapshot. After every release, open the active address outside the studio and verify hostname, secure connection, language, visible content and version. If external hosting or domain routing is unfinished, record it as an external launch blocker instead of substituting an internal preview address.

Prove a controlled live booking end to end

Run the live booking only in the isolated demo or designated test hotel with clear test data. Never simulate payment success.

Before submission verify product, nightly rates, extras, tax, policy, payment and total. Submit once and confirm exactly one booking record.

Open the PMS booking, verify source, guest, stay, plan, extras, price, status and payment, then inventory and confirmation email. Clean up through the approved cancellation process.

The live proof must use only the isolated Hotel Nordlicht demo or another explicitly approved test hotel. Choose available dates, an internal test address and unmistakable test notes. Review category, plan, nightly price, extras, visitor tax, cancellation policy, payment method and total before submitting once. Then verify exactly one PMS booking, the expected request or confirmation status, the Booking Engine source, guest and stay data, and any provider-backed payment information. Check that category inventory has decreased and that the correct-language confirmation contains the real dates, amount, policy and sender. Finish through the approved cancellation and cleanup workflow so audit history remains intact. Never use an existing customer account or simulate a successful payment.

Monitor after publication and safely go offline

Use a tighter monitoring window for the first 48 hours or five bookings. Review source, price, inventory, confirmation and repeated guest friction.

For critical price, inventory, checkout, policy or confirmation errors, unpublish. History remains; fix the source and rerun affected tests before republishing.

Normal changes follow draft, preview, readiness, mobile/language review and publish. Assign content, pricing and final approval ownership even if one person holds several roles.

For the first 48 hours or first five genuine direct bookings, assign a named daily review. Compare booking source, rate and total, inventory reduction, confirmation delivery, open requests and repeated guest questions. A technically successful checkout can still contain unclear policy wording or a difficult mobile step, so log device, language, stay dates and the exact point of friction. Wrong prices, phantom availability, a broken mandatory checkout, an incorrect policy or a missing confirmation are stop conditions: unpublish, record the affected period and bookings, correct the central source and repeat the relevant matrix before a second approval. Routine changes follow the same controlled path from draft to review and publication.

Close the follow-up inspection in the same form of evidence as the start: it should be visible who checked what, in which language and device, what the expected result was, what actually happened, and where the related booking or screenshot is located. Thus, a subsequent price change, a new room category or a modified cancellation condition does not require a complete restart, but rather the affected control circle can be precisely designated. The person in charge closes the release only if the public page, the booking coming into the PMS, the inventory change and the message sent to the guest prove the same approved offer.