Complete a full check-in

Approve booking, arrival date and room before check-in

Open the specific arrival and verify booking number, status, today’s arrival, departure, adults, children, category and active room allocation. Correct wrong dates before changing lifecycle state.

A sellable room is not automatically ready. Ready means vacant, cleaned and checked; stayover-service-done is not a free arrival room. Resolve defects and housekeeping work first.

Open the exact booking and verify booking number, confirmed state, arrival and departure, category, party, assigned room, payment situation and material notes. Check-in belongs to the intended arrival day; a wrong date is corrected in the booking rather than bypassed at reception. The physical room must be assigned, active, not blocked and genuinely ready for occupancy. Housekeeping finished is not automatically the same as ready, and management must not invent readiness to make the dialog pass. If maintenance, a room block or a different guest occupies the room, resolve inventory and room assignment first. Record the one responsible decision when an exception needs escalation. The pre-check succeeds only when the saved booking and real room can accept the same arriving party now.

Register all arrivals and reuse existing profiles

STRYK creates one guest slot per booked adult and child. Complete every actual identity; resolve count differences in the booking before completion.

Search for an existing profile per person. Reuse reliable matches, update only verified fields and never collapse companions into the main profile.

Compare booked adults and children with the people actually arriving. The check-in creates one guest slot per booked person; complete every slot and never leave an unnamed companion as a placeholder. Confirm the main guest against the booking, then search each companion before creating a new profile. Use several matching facts such as full name, birth date, email, phone and previous stay, not a name alone. Reuse an existing profile when identity is reliable, update only verified changed details and create a separate person when identity remains uncertain. If the real party differs from the booking, correct the authorised booking facts before completing registration. This keeps guest history, occupancy, tourist-tax inputs and later communication attached to the right individuals.

Complete fields required by the property configuration

First and last name are required for every person. Other required markers come from the central configuration and may include salutation, title, email, phone, birth date, nationality, address and custom fields.

Do not copy old values blindly. Confirm contacts and address. An optional birth date may trigger a conscious warning; a configured required date blocks progression until supplied.

Complete fields per person from the current property configuration. First and last name are always required; salutation, email, phone, birth date, nationality, address and custom fields may become mandatory for this hotel. Read the visible marker and validation instead of relying on an old paper checklist. Enter facts from the guest or approved document, preserve correct spelling and do not fill a required field with invented content. Birth date deserves explicit treatment: when required it blocks progression; when optional with an active warning, continuing without it is a deliberate exception that needs a real reason, not a routine click. Review every person again after switching between guest slots so one companion does not inherit another person’s contact or nationality.

Apply document requirements by nationality and person

Central configuration can require documents for everyone, everyone except listed countries, non-EU/EEA guests or selected countries. Correct nationality is therefore essential.

Complete documents per applicable person: type, number, issuing country and required dates. Review any protected scan for file, format and readability; skip only when the configured case allows it.

Apply the configured document rule to each individual, not only the main guest. Determine whether the person is in scope from nationality and the hotel rule, then capture only the fields shown as required: document type, number, issuing country and applicable issue or expiry dates. If a protected scan is required, use the product flow and approved device; do not place document photos in notes, email drafts or an unprotected local folder. Match the number and country with the physical document and confirm which guest slot owns the record. A missing required document blocks completion. When no document is required for that person, do not collect one merely because another companion needed it. This person-by-person decision limits sensitive data while meeting the configured operating requirement.

Review extras and notes before handover

Choose only confirmed active extras and review price, currency and calculation: once, per night, per guest or per guest per night. A chargeable service belongs as an extra, not only in notes.

Use notes for concrete handover, not as a substitute for master data, payments or room blocks. Keep them factual and action-oriented.

Review check-in extras against the real request and configured calculation. Confirm whether the price is fixed, per person, per night or per person and night, then compare quantity and total with party and stay. For two adults over three nights, a breakfast priced per guest and night must use six units. Do not add a service because it is common; confirm it with the guest and make sure it was not already included in the rate plan or booking. Read the new booking total after selection and record a concise operational note only when it helps delivery. Allergy, accessibility or arrival details belong in the appropriate authorised context and should contain no irrelevant sensitive narrative. The handover is ready when service, calculated amount and responsible hotel team all describe the same promise.

Review summary and complete check-in once

Review booking, guest, room, dates, all people, documents, extras, total and note. Return to the relevant step for any discrepancy, especially with multiple guests.

Complete once and wait. On success STRYK saves registrations, links the main guest, adds extras, sets in-house and changes the active room to occupied/service-required. Errors keep the dialog open.

Use the summary as an eight-part final gate: booking and room, booked and actual party, every guest identity, configured required fields, per-person document requirements, selected extras and calculation, operational note, and resulting amount. Move back to the responsible step for every mismatch and regenerate the summary. Complete check-in once and wait for the success result; repeated submission after a slow response must not be used as a troubleshooting method. If STRYK cannot complete check-in, keep the booking unchanged and follow the displayed correction. Finish only when the booking and room status have updated successfully.

Review in-house, room state and exceptions after completion

Reopen the booking: it must be in-house, check-in no longer available and the active room occupied/service-required. Compare registered guests, main profile and updated total.

An error leaves state unchanged. If the wrong booking was actually checked in, use the reasoned undo-check-in workflow and verify restored booking and room states; do not cancel or edit status manually.

After success, reopen the booking and room rather than trusting the toast alone. The booking should be In-house, the assigned room should show the occupied operational state, registered guests should match the arriving party and selected services should remain on the stay. Verify that the correct room, not another room in the category, changed state. Check the guest profiles and booking link so later messaging, registration and checkout use the same people. If one layer differs, stop and report booking number, room, expected state, observed state and time; do not repair it by inventing a second check-in. A professional exception remains visible and assigned until the source is reconciled. Check-in is complete only when real people, guest records, booking, room and services describe one contradiction-free in-house stay.

For the shift handover, prepare a short check-in proof line: reservation number, day of arrival, assigned room, registered adult and child, complete document requirements, received extra, new reservation amount, closing time and executor. The next colleague should open the source records from this, do not copy personal data from the line. Check the Housekeeping and occupancy status of the room separately: the change from move-in to occupied must belong to the same room and stay. If the guest arrives later, but the check-in has already been closed, clarify the real situation according to the approved operating process; don't leave an unreasonable Inhouse status just because the dialogue was successful. The purpose of the proof of closure is not to create a new side record, but to quickly verify that all credible sources show the same arrival.