Find the repetition, then define the outcome
The best first automation is rarely the most spectacular one. It is usually work you repeat every day using the same information. Write down the trigger, required data, responsible person and evidence that it completed correctly.
The next-day briefing
At a defined time, gather arrivals, departures and follow-up items for the team. Check the period and time zone first. Highlight exceptions: a special arrival or an outstanding intervention is more useful than a booking list without context.
Preparation after a new booking
A booking can trigger a task or an event in a connected calendar. Start with one action and one test property. Then check a changed or cancelled stay: useful procedures also need to account for moving dates.
The reply draft
Recurring questions are a good fit for writing assistance. Prepare a reply using stay and property information, then review it before sending. Once the procedure is clear and tested, decide which steps warrant further automation.
Test before expanding
Check the connected account, recipients and dates. Inspect results and errors in the run log. Add a condition when a workflow should not apply to every property. Imported Keyful workflows start paused, so each module can be reviewed before activation.
Three workflows, ordered by how easy they are to check
A good first workflow has a clear, verifiable output. An internal briefing is easier to review than a sequence of guest messages. Start with your own test address before sharing the procedure with the team.
| Workflow | Trigger | What to verify |
|---|---|---|
| Arrival briefing | Every day at 9 am | Correct date and properties; one message |
| Stay preparation | New booking | One task linked to the right booking |
| Intervention follow-up | Schedule + task still open | No reminder for completed work |
The instruction to give Ocho
Specify the trigger, source data, recipient and exceptions. “Automate arrivals” leaves too many implicit decisions. The instruction below gives you something testable.
In the editor, choose specific actions and the accounts that execute them. Check conditions and fields passed between modules: a guest name should not replace a stay identifier. Names repeat; references help prevent duplicate work.
Every day at 9 am in Europe/Paris, prepare today’s arrivals for my organization’s properties. Exclude cancelled bookings. Group stays in one briefing with property, known arrival time and items to check. Prepare an email to [test address]. Keep the workflow paused so I can review it.
Test what should do nothing, too
Try a day without arrivals: the workflow should produce your intended outcome, such as an explicit empty briefing or no message. Replay the same event: it should not create another identical task. Test a cancellation and a date change.
A simulation checks the proposed flow. It cannot prove that an external account will authorize a send. Follow it with a real test to an address you control, verify receipt and inspect the run log. Activate one procedure at a time so that failures remain understandable.
Keep a way back
Name the workflow owner and document where to pause it. Keep an export after meaningful changes. If a connected account is revoked or an app is unavailable, the team must know where to find the failure and how to continue manually.
Useful automation removes repetitive follow-up. It should not make an exception impossible to handle.
