Choose the right first workflow
Automate frequent, clear and low-risk work first, not the most complex exception.Describe the current manual workflow in one sentence containing occasion, audience, timing, action and control. Vague goals such as “inform guests better” are not ready for automation.
Assess frequency, effort, impact and exceptions. Arrival information is a good start; refunds or unresolved goodwill cases are not. Hotel Nordlicht starts with one paused guest message and two internal rules.
| Question | Ready | Keep manual |
|---|---|---|
| Does it happen often? | Daily or weekly | Rare exception |
| Is the right outcome clear? | One defined message or task | Needs individual judgement |
| Can exceptions be identified in data? | Source, category, tag or period | Only known by individuals |
| Can it be tested safely? | Demo booking and controlled recipient | Immediate financial or contractual effect |
Organise automations in the Guests workspace
The overview is the control centre: active, paused, last run and today’s executions should be clear at a glance.Open Guests → Automations. Review existing rules first to prevent duplicates. Name rules by moment and purpose, not internal abbreviations.
Use templates only as a starting point. They do not know your hotel details. Keep them paused until content and audience are tested. Hotel Nordlicht separates message, tag and housekeeping task.
Set trigger and timing correctly
The trigger describes what happens in the hotel; delay defines when the action should run around it.Choose the event that represents the actual hotel moment. STRYK distinguishes booking, stay and finance events. A booking confirmation is not a check-in, and a modification is not a new booking.
Then set the timing relationship. Hotel Nordlicht chooses Before arrival, 2 days, before event. State the resulting sentence aloud. Use zero delay for immediate events and date ranges for seasonal rules.
| Goal | Matching trigger | Key control |
|---|---|---|
| Confirmation after direct booking | Booking confirmed | Once only and correct channel |
| Arrival information | Before arrival, e.g. 2 days before | Cancellation and missing contact |
| Preparation after online check-in | Online check-in completed | Data complete, task clear |
| Post-stay follow-up | After departure | No unresolved complaint or exception |
| Internal payment notice | Payment received or due | Amount and owner clear |
Limit the audience with a few reliable conditions
A rule is not better because it has many filters, but because every filter has a documented hotel reason.Start with booking source and room category. The example covers direct and manual bookings; OTA bookings stay out until content and booking-bound channel are tested separately.
Use advanced conditions for concrete exceptions such as minimum nights, an Early arrival tag or seasonal dates. Document one matching and one non-matching example for every condition.
Write the action and message to complete the job
Automatic delivery saves time only when content, channel and next step are complete.Choose the action that matches the outcome: guest message, internal notice, tag, housekeeping task or internal note. Webhooks are an expert path requiring an agreed external system and error process.
For guest messages, Automatic preserves the booking context. Test direct and OTA cases separately. Subject, opening, useful content and contact should be concrete; placeholders must resolve in the test booking.
Arrival information in five review sentences
- 01Occasion
Subject says “Your arrival at Hotel Nordlicht” instead of generic marketing.
Immediately clear - 02Context
Name and stay use verified booking data only.
No empty placeholder - 03Value
Check-in time, address or directions answer a real guest question.
No filler - 04Next step
Guest knows whether to reply, check in online or simply arrive.
- 05Contact
A monitored reply route is provided.
Team owns it
Set guardrails and test with two bookings
Before activation, the rule must match once and deliberately not match once.Enable once per booking, set a sensible daily cap, document priority only where rules share a moment and use active dates for true seasonal boundaries. Skipped runs remain visible.
Create two demo bookings: one matching every condition and one violating exactly one condition. Run the integrated test and inspect rendered content, placeholders, action and result. Keep the rule paused until approval.
Approval before activation
- The workflow sentence names occasion, audience, timing, action and control.
- One match and one deliberate non-match were tested.
- All placeholders show real test values instead of blanks.
- Once-only, daily cap and seasonal window are justified.
- A responsible person reviews the log on the first operating day.
Activate, read the log and improve in control
Automation is not finished when switched on. Its first real runs are part of acceptance.Activate during a staffed window. Review the overview and execution log after expected runs. Successful, skipped and failed each require interpretation; pause immediately when external impact is unclear.
After seven days review saved manual steps, questions and exceptions. Change one variable at a time and retest. Pause rather than deleting evidence. After 30 days management decides whether the rule stays.
| Status | Meaning | Next step |
|---|---|---|
| Successful | The configured action ran. | Spot-check content and booking context. |
| Skipped | A guardrail or condition prevented the run. | Confirm the exclusion was intended. |
| Failed | The planned action could not complete. | Pause, fix cause and repeat the test. |
| Test | The rule was checked in a controlled run. | Do not confuse it with a real event run. |
