A workflow does something for you whenever a certain moment comes around: a stay is booked, a guest checks out, it is three days before check-in. You pick the moment, optionally add conditions, and choose what happens: an email to the guest, an email to someone on the team, or a task.
Workflows are still being tested, so only SERVOS staff can see and edit them. If SERVOS has set one up in your organization while testing, its emails and tasks show up as usual, but you can't open or pause it yourself; ask SERVOS to change or stop it. Once workflows are on for everyone, owners and admins can see and edit them. If you cannot see Workflows in the sidebar yet, that is why.
Building a workflow
Press New workflow on Workflows. The workflow opens as a diagram that reads top to bottom: the trigger first, then each step in the order it runs. Select any box to edit it in the panel beside the diagram, and give the workflow a name by editing the title at the top.
Selecting a workflow in the list opens its own page, with a preview of the diagram and the runs below it. Press Edit there to change it.
Triggers
The trigger decides when the workflow starts and what it is about. Each run belongs to one record, the stay, order, customer, or guest that set it off.
- Stay: Stay is booked, Stay is cancelled, Guest checks in, Guest checks out, and Stay dates change.
- Order: Order is placed and Order is cancelled.
- Customer: Customer is created and Customer places an order.
- Guest: Guest is added to a stay, for someone registered on a stay rather than the person who booked it.
Stays, orders, and customers also have a time trigger, "Time before or after a … date". It counts from a date on the record: the check-in or check-out date of a stay, the order date, or the date someone became a customer. It can reach up to 90 days either side, so "2 days before check-in" and "1 day after check-out" are both a single trigger.
A time trigger fires once per record and date. If a stay's dates move before the moment arrives, the workflow waits for the new date instead. Time triggers are checked every few minutes, so expect a run a few minutes after the exact moment rather than on the second.
A stay booked, or moved closer, after its moment has passed still runs straight away while check-in is ahead, so a stay booked the day before check-in still gets a "2 days before check-in" email. Once the date itself has passed, it doesn't.
About a booking, or news and offers
Under the trigger, "Emails are" says what the workflow's emails are for. About a booking, the default, is for emails every guest needs, like arrival details. News and offers is for marketing: a "come back" email, a seasonal offer, an upsell. A marketing workflow emails only customers who agreed to marketing emails from you, and each email ends with a link to unsubscribe. Mail apps that support it also show an unsubscribe button next to the sender. Someone without consent is skipped, and the run says so.
Marketing law asks for consent before you send offers by email, so choose News and offers whenever an email sells something. See Customer profiles for where consent comes from.
Actions
- Send email emails the record's customer or guest. Pick the address under "To", then write a subject and message. An address that never reaches the guest, like a Booking.com relay address, is skipped.
- Email team member emails one or more people on your team.
- Create task adds a task with a priority, an optional assignee (a person or a team), and an optional due time. The task is pinned to the stay or order the workflow ran for, so it shows up there too.
- Send pre-check-in email sends the stay's pre-arrival registration request. It is only offered on stay triggers. It sends once per stay, so a stay that already got the request, from the built-in reminder or from an email with the Guest registration link, is left alone, unless you turn on Send again if it was already sent for a second reminder. It skips stays booked through an OTA, stays whose guests are all registered, and bookers without an email address. See Guest registration.
- Wait pauses the workflow, for up to 90 days, before the next step.
Conditions
A condition splits the workflow into paths. Each path has one or more rules, like "Booking source is Direct" or "Nights is at least 3", and the first path whose rules match is the one that runs. If none match, the "else" path runs, which can be left empty to stop there.
Rules can be joined with "and" or "or". "And" is checked first, so "A and B or C" means "both A and B, or C on its own".
Rules can look at the record itself and at what it is linked to. A stay workflow can check the stay's customer, and a guest workflow can check the stay the guest is on.
Amounts, like an order's total or balance due, are entered in your organization's currency, the same way as prices elsewhere in SERVOS.
Filling in names, dates, and amounts
Emails and task titles can include details from the record. Use Insert a field… to add one; it appears in the text as a token such as {{stay.customer.name}} and is replaced with the real value when the workflow runs. Dates are written out in full and amounts include the currency. A field that is empty on the record comes out as nothing, so read the sentence back with that in mind.
Links
In a Send email message, write a link as
[Register your guests](https://…). In a paragraph of its own, with a blank
line before and after, it shows as a button; inside a sentence it is
underlined text. A web address typed on its
own becomes a link too.
Stay and guest workflows can insert Guest registration link, which opens the stay's guest registration without signing in, so you can write your own pre-check-in email instead of using Send pre-check-in email. It goes in as a link named "Guest registration link"; change the text in the brackets to your own words. It lasts until the end of the day after check-out; if the stay's dates change, a link already sent follows the new check-out. A link that has lapsed no longer opens the stay, but the guest can still open it with the booking reference and last name. Once an email with the link has gone out, the built-in reminder and Send pre-check-in email skip that stay.
Drafting an email with AI
On Send email and Email team member, the sparkle button next to Message drafts the email for you. Describe what the email should say, for example "welcome the guest and share how to find the key box", and press Draft. After a few seconds the subject and message are filled in, with fields from the record where they fit. If the message already had text, press Undo on the notice that appears to get it back. Choose a trigger first: the fields come from it. On Email team member the draft is a short note to colleagues. Read it through and adjust it: nothing is sent until the workflow is published and runs.
Publishing
Nothing runs until you publish. Save draft keeps your changes without touching what is live; Publish makes the workflow active. Publishing checks that every step is filled in and points out anything missing.
After that, edits stay a draft until you press Publish changes. Each publish becomes a new version. Runs already under way, for example ones sitting in a Wait, finish on the version they started on.
A workflow only reacts to things that happen after it is published. Publishing a "2 days before check-in" workflow does not reach back to stays whose moment has already passed.
To stop a workflow, open More on its page or in the editor and choose Pause. Anything still waiting is skipped when its wait ends. Press Resume to start it again; moments that passed while it was paused are not caught up. If you have edited it since, the editor's button reads Publish and resume and publishes your changes too. Delete in the same menu removes it for good.
Checking what ran
The workflow's page, opened from the list on Workflows or from More → View runs in the editor, shows a preview of the published version and lists every time the workflow started, newest first, with the record it ran for. Until the first publish the preview shows the draft and is marked Draft; with unpublished changes it shows the published version, marked Published version. Each run shows one of these states:
- Completed: every step ran. The outcome shows the email sent, the task created, or why an email wasn't sent.
- Waiting: the run is sitting in a Wait step, or retrying a step after the email service failed. It tries four more times over about four hours before it fails.
- Skipped: the run was stopped before doing anything, with the reason. A cancelled stay or order, a deleted record, a walk-in customer, a paused workflow, or stay dates that moved are the usual ones.
- Failed: a step could not finish, for example because the customer has no email address. Steps after it do not run.
Emails sent by a workflow also appear on the stay, order, or customer's activity, the same as the emails SERVOS sends on its own. Completed and skipped runs are kept for 180 days.
Common questions
Who do workflow emails come from? The same as the rest of SERVOS's emails to customers: a servos.dk address with your organization's name as the sender, and replies go to your organization's email address. See Emails SERVOS sends.
Why did a cancelled stay not get my email? Workflows skip cancelled stays and orders, so a "3 days before check-in" email does not go to a guest who has cancelled. The exception is the Stay is cancelled and Order is cancelled triggers, which exist for exactly that moment.
Will guests who booked through an OTA get my emails? No. A customer who booked through an OTA such as Booking.com has a relay address from the OTA, which does not reach the guest, so a Send email step to it is skipped and the run says so. To leave those stays out of the whole workflow, tasks included, put the steps behind a condition "Booking source is not OTA".
Walk-in customers have no email address, so workflows about them are skipped. Any other run without an address to send to fails and says so in the runs on the workflow's page.
Can a workflow send the same email twice? Each trigger starts one run per event, and a time trigger once per record and date. Two separate workflows with the same trigger will both run, so check for overlap before publishing a second one.
