Build a journey

A journey is a line of steps that runs for one person at a time, starting when something happens to them. A bot holds a conversation; a journey runs a sequence, and the person doesn't have to be there for it.

You build it on the canvas: a trigger at the top, steps beneath it. Journeys are on the Scale plan; bots aren't.

Plan with Qyra

Describe the outcome you want. Qyra checks existing automations and proposes whether to create another one, change an existing one or keep the current setup. Review the proposal and choose the exact automation when changing an existing one. If an existing automation needs attention, review it before adding a second one.

Qcom already sends eligible Order, Booking and Payment notices. For a Journey using one of these notices, choose whether to keep the automatic message, explicitly replace its message or add a different follow-up. Replacing a message does not change how the Order, Booking or Payment is processed. Review the delivery result before assuming the customer received it; a draft is not proof of delivery.

The wording of these automatic notices cannot currently be edited directly. Appointment reminder timing is part of the item's Booking terms. Customer preferences, connected channels and delivery requirements still determine whether a message can reach someone.

If Qyra cannot check the current setup, refresh and try again. Choosing to keep the setup or review a different solution does not create an automation draft.

Choose the Catalog items

Choose Everything, item types, categories or individual items in the automation's Catalog settings. The same choices are available in the mobile automation settings.

Everything, types and categories can include newly eligible items in future runs. Individually chosen items stay fixed. Changing the Catalog does not add items to a run that has already started.

An Order can start the automation when any of its items matches. Steps about those items stay limited to the matches. An invoice for the complete Order needs an explicit Complete Order choice; its amount still comes from the Order.

An invoice or support ticket without a Catalog item can start an automation only with Everything selected. A customer journey can also introduce selected items before a purchase, without treating the customer as having bought them.

Selecting an item does not add promotions, review requests or other steps. Tell Qyra what you want to achieve. Customer permissions, communication preferences and the rules for each action still apply.

It starts with one trigger

Every journey begins with something that happened — a contact created, a tag added, a segment entered, a form submitted, a lead moving stage, an order placed or completed. See Choose what starts an automation for the full list and what each one really fires on.

The trigger makes someone a candidate to enter. The journey's entry rules, previous runs and any repeat-entry waiting period still decide whether they can start. An event occurring does not prove a run was created.

Three kinds of step

Messages — Send Email, Send SMS, Send WhatsApp, Send WhatsApp Flow.

Waiting — the part that makes a journey a journey rather than a batch send:

• Wait — a fixed amount of time before the next step.
• Wait for Form Submission — wait for the intended Form submission, not just an opened form or saved draft.
• Wait for Payment — wait for the payment linked to this path; an unrelated payment or a customer's claim is not confirmation.
• Wait for Decision — wait for the required approval or rejection.

Wait can use a duration or a fixed date and time. Fixed times are shown in UTC. A time that has already passed resumes immediately. Loading and saving a wait keeps its full duration, including any combined units. An incomplete or invalid wait must be corrected before publication.

A waiting step holds that person where they are. Everyone else keeps moving — nobody queues behind anybody else.

Check each wait's limit and what happens when it expires. A timeout does not prove the customer declined or that no payment moved; inspect the linked record before requesting another attempt.

Doing — the steps that change something rather than say something: Add Tag, Remove Tag, Update Contact, Move Lead to Stage, Assign Conversation, Notify Team, Create Support Ticket, Create Reminder, Ask for Feedback, Request Payment, Place Order, Create Invoice, Create & Schedule Campaign, Pause or Cancel Campaign, Mark and Check Milestone, and Start Customer Journey — which hands someone to another journey.

Notify Team needs an email template and a teammate to receive it. Internal workflows can use their enrolled teammate when no recipient is selected. Notification preferences can prevent delivery; check the step result before assuming an email was sent. A submitted email is not proof of delivery. If its send outcome is uncertain, Qcom checks the saved delivery result without sending another email. If those checks still cannot confirm the outcome, the run stops. Check the existing email before trying again.

Create Reminder, in internal workflows, creates a reminder due after the selected delay. It uses the selected teammate, then the conversation assignee, then the enrolled teammate. A run with no available conversation or recipient records the step as skipped.

Create & Schedule Campaign requires a future send time when you choose a fixed schedule. A missed time stops that step; it does not turn the campaign into an immediate send. Review the schedule before retrying.

Branching

A condition splits the line: people who match go one way, everyone else the other. Both paths carry on as journeys of their own.

Branch on what you know about the person at that moment — a tag they now have, a stage they've reached, or a membership they hold.

Check Milestone and Mark Milestone use workspace activity flags, such as the first contact added or first email sent. Check Milestone stops the run when that workspace flag is already recorded. These flags apply across the workspace; they do not measure an individual customer's success. Use a Goal for a supported customer outcome.

A membership branch covers anything you sell. When you mean one item, save a segment for it and branch on Is in segment.

When Qcom can't answer a condition for somebody, they take its Data unavailable path. Leave that path empty and they'll stop there.

How someone leaves

A Journey does not use the operations flow's End step. Reaching the end of the path completes a run; if exit on reply is enabled, a customer's reply can end it before then. A failed step is a different outcome. A Goal measures a supported business outcome and stops further steps only when you choose that behavior. Reaching the end does not prove success. See Goals, and how someone leaves a journey.

Retry part of a Qyra draft

For a long automation built by Qyra, the draft preview can show Sections. Choose Retry beside the section you want Qyra to build again. The other sections and the automation's starting and enrollment settings stay the same. Retrying a section uses the original build's credit charge.

Review the new draft before saving it. Retry creates another draft version; it does not publish the automation. If the draft changed in another editor, reopen its latest version first.

Before you turn it on

Define the intended outcome. Choose a supported Goal and the step whose record it measures. Set the measurement window and whether success should stop further steps. Keep the Journey as a draft if its required outcome cannot be measured.

Walk one path end to end. Each step can look reasonable while the whole thing isn't — two branches that both send give somebody three messages in two days.

Check the waits against real life. An hour and a day look the same on the canvas and feel very different to the person waiting.

Remember it runs per person. A hundred people can be on a hundred different steps.

When the expected result doesn't happen

• Nobody entered: check publication, the trigger's exact event and the intended audience. A contact already in a Segment is not a new entry event. Review repeat-entry rules before assuming the trigger failed.
• Someone is waiting or has exited: inspect that person's run and its reason, including wait limits and exit on reply. Another person's progress does not prove this run should advance.
• A step could not complete: check its saved result and the owning payment, order, Form or other record before retrying. Ask the Qcom team to investigate an uncertain outcome rather than starting a duplicate run.

Save and publish the reviewed version, then test the intended trigger with an authorised test contact. Reopen their run and check the messages and saved business outcomes. Preview and a successful trigger alone do not prove the whole journey worked. See Save, publish, and go live.

Related

• Goals, and how someone leaves a journey
• Choose what starts an automation
• Create an automation
• Hand a conversation over to a person
• Where you can use a segment