Define ownership and the launch target state
A small team needs no large project organisation, but every decision needs an owner.Name owners for property and finance data, rooms and pricing, plus one test user each for front desk and housekeeping. Small properties may combine people, but approvals remain distinct.
Write the target state before setup: real rooms in clear categories, traceable prices, separate users, a visible housekeeping plan and one test booking. Portal connections and data migration each receive their own acceptance test.
Define the launch owner, module owners and measurable day-one target before entering data. Name who approves hotel identity, rooms, pricing, finance, users, housekeeping and the final test stay. Give portal connections and data migration their own acceptance tests and release them only after the checks pass. Create one checklist with source, responsible person, review date and evidence for each item; “configured” is not evidence until the saved value is reopened and used in a workflow. Set a freeze window for room and rate changes during the final test so the result is reproducible. Agree on a stop rule for missing legal, tax, inventory or access facts rather than filling them with demo assumptions. The launch plan is ready when every critical decision has one owner, one source and one acceptance test, and the team understands what must work on day one versus what may follow later.
| Area | Decision | Visible evidence |
|---|---|---|
| Property & finance | Official identity, contact, tax and invoice details | Saved settings and document preview |
| Rooms & sales | Categories, capacity, rooms, base price | Rooms and pricing views agree |
| Team & operations | Users, roles, housekeeping ownership | Each test account sees the correct workspace |
Save property identity and operating standards completely
These details appear in many places, so they need one responsible source.Open Settings → Property and verify official name, address, country, time zone, currency, default language, phone and monitored email. Time zone controls the operating day.
Then review invoice and tax details in Finance. Save section by section and confirm the values reload after navigation.
Complete the property identity from verified business sources. Save official hotel name, address, contact routes, timezone, default language, finance and tax details, invoice sender data and the operational policies that the product actually uses. Maintain the public domain slug deliberately and verify availability before saving; do not derive or change it casually because it controls the staystryk.com booking address and standard sender identity. Add the approved logo, corporate colours and typography at the central hotel design source so Booking Engine and documents do not carry separate variants. Configure calendar and housekeeping colours for meaning rather than decoration. After each save, wait for the visible result, leave settings and reopen the section. Compare public-facing text in all active languages where guests will see it. Identity setup passes when login context, settings, PDF preview and booking-page preview all show the same verified hotel, with no placeholder company, test contact or invented legal value.
Master-data approval
- Name and address match official records.
- Time zone, currency and default language match operations.
- Phone and email are actively monitored.
- Saved values reload identically.
Create sellable categories before physical rooms
Guests buy a room product; operations then work with the physical room.Open Rooms → Rooms & categories and create every genuinely sold category once. Maintain name, stable code, occupancy, bed type, size and descriptions in all active languages.
Then assign every physical room with a unique number to exactly one category. Maintenance and blocks are not handled by deleting the room; housekeeping state is not long-term inventory.
Create sellable categories before physical rooms. For each category define a guest-understandable name, minimum and maximum occupancy, adult and child capacity, bedding, relevant amenities and truthful descriptions in all active languages. Add approved photos that actually show that category. Then create every physical room exactly once with stable room number, floor or location and one category assignment. Reconcile the resulting count with the property’s signed inventory list. A room is not a second category, and a category is not a single physical unit; this distinction is the basis for availability, pricing, Booking Engine and later channel mapping. Keep inactive or permanently removed units explicit rather than renaming them into unrelated rooms. Test category expansion and room rows in the shared Rooms view. The inventory setup passes when management can trace every door to one room record, every room to one sellable category and every published capacity or image to a verified physical truth.
| Level | Example | Controls |
|---|---|---|
| Room category | Nordlicht Double Room | Sellable product, capacity, description, price context |
| Physical room | Room 105 | Assignment, floor, operational use |
| Housekeeping state | Ready or cleaning open | Daily state for front desk and housekeeping |
| Block | Maintenance 4-6 August | Availability in the affected period |
Verify base prices and bookable rates with test stays
A stored price becomes reliable only when it can be explained for a concrete stay.Open Pricing and verify the base price for each active category. Activate only real rate plans whose name, services, cancellation and payment terms describe one coherent choice.
Pre-calculate three stays, then compare category, nights, occupancy, rate and total in the booking workflow. Document differences instead of masking them with manual prices.
Configure base prices by category and date, then create only the rate plans the property is prepared to sell. For every rate, verify name, cancellation and payment conditions, included services, active sales period and relation to the base price. Add a direct rate plan before testing the Booking Engine; public booking must not fall back to an invented default rate. Use several test stays: weekday and weekend, one and several nights, season boundary, different party sizes and each active category. Compare nightly prices, restrictions, extras, taxes and total. A closed or capacity-limited date must remain unavailable. Do not publish a rate because its label looks correct; prove the STRYK calculation and the exact guest-facing conditions. If a price is missing or a calculation fails, stop instead of typing a compensating manual total. Pricing setup passes when every active combination produces an explainable quote and every intentionally unavailable combination fails visibly and correctly.
Approve personal team access and roles in practice
Every person works under their own name with the rights their job requires.Open Settings → Users & roles and create one personal account per employee. Assign roles by responsibility and reserve full access for few owners.
Test front-desk and housekeeping accounts for visible navigation, allowed actions and expected restrictions. Correct permissions centrally and sign in again.
Create one personal account per employee and assign access from real tasks, not job-title prestige. Start with the smallest role that lets front desk, housekeeping, finance or management complete approved work. Never share an administrator login across shifts. Verify language preference, active state and hotel assignment, then test each role with one allowed and one forbidden action. A housekeeper should reach the day plan without receiving finance settings; a receptionist may process bookings without managing users; a finance user should see the required documents without unrelated administration. Record who approved elevated access and its review date. Test absence cover with a temporary, explicit role change rather than sharing credentials. If someone leaves or changes responsibility, deactivate or adjust the personal account promptly and preserve audit history. Team setup passes when every action can be attributed to a named user and forbidden areas fail visibly instead of being hidden only by convention.
Run one complete test booking through operations
Now test the interaction, not individual settings.Create a clearly marked test guest booking in the separate demo hotel. Use two nights, two adults, an active category, a verified rate and payment method. Search for the guest first.
After saving, open calendar, guest profile, rooms workspace and the housekeeping plan. The same stay must be recognisable everywhere. Move the room through the actual status steps from preparation to ready.
Run one complete booking in Hotel Nordlicht using controlled test data. Search or create the correct demo guest, book an available category and physical room for several nights, select the verified direct rate, add a calculated extra and save once. Prove the booking in detail, calendar and guest profile. Move it through arrival preparation, housekeeping readiness and check-in with all configured guest and document rules. Create an invoice or quote from the real services, record only a test payment that is explicitly part of the controlled scenario, and verify the resulting balance. Complete checkout and confirm room and availability return to the correct operational state. Repeat one negative case such as unavailable room, forbidden user action or missing required field and verify the system blocks it. The end-to-end test passes only when all connected modules agree on guest, stay, room, price, payment and state without manual shadow data.
First complete test case
- 01Search guest
Check name and email before creating.
Exactly one guest profile - 02Record stay
Set dates, guests, category and rate.
No availability warning - 03Check total
Recalculate nights, extras and total.
Difference €0 - 04Open calendar
Find the stay once in the correct room context.
Dates and status match - 05Check handover
Compare guest profile, room state and housekeeping plan.
One shared operating state
Approve day one and separate future expansion
Launch ends with a decision, not an endlessly growing task list.Run a 20-minute acceptance with management, front desk and housekeeping. Compare the target values with evidence in STRYK. Core data, rooms, pricing, roles and the test booking may block launch. Portal connections, data migration and additional automations are approved with their own test cases.
Record approved areas, test reference, tested users, non-blocking items and the next review. On the first live day, management checks arrivals, room state, payments, housekeeping handovers and documents.
Approve day one with evidence, not optimism. Reopen every critical setting, review the inventory and rate matrix, sign off role tests and retain the booking number of the completed end-to-end scenario. Check navigation and public language selection in all active languages, mobile presentation of the booking page, invoice or housekeeping PDF language, and the support contact path. List open items by severity, owner and target date. Use integrations and migrated data only after setup and verification are complete. Define the daily checks for the first live week: arrivals, room readiness, pricing, payment exceptions, user access and support incidents. Establish rollback or escalation ownership for a critical inventory or finance issue. Go live when the essential workflows are reliable, every open item has an owner and the team knows how to reach support.
