The Journey That Only Starts When Another One Finishes

Most hotel marketing platforms treat every guest journey as a clean slate. A trigger fires, a guest enrolls, messages go out, the journey ends, and the platform forgets it ever ran. If you want a second workflow to depend on the first one actually finishing rather than merely starting around the same time, most builders leave you improvising: tag the guest when journey A sends its last message, then build journey B to watch for that tag and hope nothing races. It works until it doesn't, usually the week a guest gets the same win-back offer twice because two workflows both thought they owned the handoff.

GuestMaker journeys skip the workaround. A journey can be told to wait for a specific other journey to finish for a guest, and it will not enroll that guest until that exact journey has completed. Not "any journey ended," not "this segment now contains them." The one you named.

What a journey triggered by another journey actually means

Under the trigger menu sits journey.completed, one of eighteen triggers spread across six categories. Configuring it means picking one or more source journeys by id, not a category, not a tag, not a guess based on timing. A guest only satisfies the trigger once one of those named journeys has actually run its course for them, branch and all, end node reached. If the source journey never completes for a guest (they exit early, they never matched a branch, whatever the reason), the dependent journey never fires either. That's the whole point: the second workflow is downstream of a real event, not a proxy for one.

This matters more than it sounds like on paper. A welcome sequence that ends in three different places depending on how a guest responds isn't "done" the moment it starts. It's done when a guest lands on one of those end nodes. A second journey that's supposed to pick up from there, say, a satisfaction check a few days after checkout, but only for guests who made it through the welcome sequence rather than dropping out of it, needs to know the difference between "started" and "finished." journey.completed is built to know that difference.

Inside a real, multi-step guest journey for a hotel group

The shape this takes in production isn't a straight line. A chained journey we've seen run like this: it fires off journey.completed for a named source journey, then sits on a delay-until node so it doesn't jump the guest immediately. From there it hits three nested conditional-split nodes, forming a small decision tree. Each of the three resulting branches ends in its own distinct email template, tailored to that branch's outcome rather than one generic message with if-then copy inside it. Before any of those three emails actually goes out, a send-at-time node controls the hour of day the message lands in the guest's inbox, so a branch resolved in the middle of the night doesn't fire in the middle of the night. Each branch then closes on its own end node.

Nothing about that structure is a toy example. It's a real, production-shaped decision tree: one entry point, one wait, three-way branching logic, three distinct sends, timing control, and three separate finish lines. The value of the journey.completed trigger sitting in front of all of it is that the whole tree only starts once the guest has genuinely come out the other side of whatever came before it.

Eighteen triggers behind GuestMaker's hotel guest journey builder

Chaining is one trigger among eighteen, and it's worth seeing where it sits relative to the rest, because the interesting part of a hotel guest journey builder isn't any single trigger, it's how many different real-world events can start a sequence without a marketer writing a workaround for each one.

Booking events cover created, updated, cancelled, and no-show. Guest events cover checked-in and checked-out. Messaging triggers respond to an inbound message, with filters for specific keywords or for a guest's very first message ever. Segments and tags cover a guest entering a segment, a tag being added, a contact subscribing, and both contact creation and contact updates, the last one watchable against specific fields rather than any change at all. Scheduled triggers cover birthdays, date anniversaries, dormant guests, and a generic scheduled trigger that runs daily, weekly, monthly, or on a cron expression for anything more particular. And then there's manual enrollment and a custom trigger fired by an external API call, for whatever a hotel group's own systems need to kick off.

journey.completed lives in that same trigger list, not bolted on beside it. That's deliberate: a journey that depends on another journey finishing should be configured exactly the same way as one that depends on a booking being cancelled, through the same trigger picker, not through a separate "advanced" mode a marketer has to go find.

Why chained marketing workflows need real sequencing, not just tags

The tag-and-watch workaround isn't wrong. It's just fragile in a specific way: it depends on the first journey remembering to write the tag at the right moment, and the second journey remembering to filter on it correctly, and nothing else in the account ever touching that tag for an unrelated reason. Every one of those is a place for a chain to quietly break, and none of them throw an error when they do. A guest just never gets journey B, or gets it at the wrong time, and nobody notices until someone happens to check.

A trigger that watches the source journey directly doesn't have that failure surface. There's no intermediate tag to drift out of sync, no separate filter logic to keep matched against a moving target. The dependency is the actual completion event, which means a hotel group building chained marketing workflows, a welcome sequence feeding a satisfaction check, a booking-confirmation sequence feeding a pre-arrival sequence, is building an explicit dependency graph rather than a set of workflows that happen to agree on a naming convention today.

Think about a multi-property group running a loyalty enrollment sequence. The group wants a second journey, one that goes deeper on the program's ongoing benefits, to reach a guest only once they've actually finished enrollment rather than the moment they joined it. Under a tag-based setup, "joined" and "finished enrollment" can look identical if the tag gets applied early to make the segment easier to build later. Under a journey.completed trigger scoped to that exact enrollment journey's id, there's no ambiguity to design around. The same logic applies to a pre-arrival sequence feeding a post-stay review request: the review ask should land on guests who made it through pre-arrival, not on guests who dropped out of it partway, and the difference between those two guest populations is exactly what completion tracking is for.

What this doesn't do yet

Worth saying plainly: this isn't unlimited chaining. What's real and shipped is a single, well-defined link: a journey depending on one or more specific, named prior journeys completing. We haven't verified that a chain runs past that one hop, journey A's completion triggering B, and B's own completion in turn triggering C, and we're not claiming it does. If your use case needs a multi-hop chain, test each link on its own rather than assuming the first hop's reliability carries through the next one.

Where this fits

None of this replaces the other seventeen triggers. It sits alongside them. The value shows up specifically when a workflow's logic genuinely depends on another workflow's outcome, not just its timing, when "after they finish the welcome series" means something different from "a few days after they arrived." That distinction is easy to blur with tags and easy to keep sharp with a trigger built to watch completion directly. If your own journey setup currently depends on a guest carrying the right tag at the right moment as a stand-in for "finished," it's worth checking whether what you actually need is a source journey id and a journey.completed trigger instead.