Skip to main content

Understand & Plan

These are the read-only ways to use the Copilot. Nothing here changes your configuration, so it's the safest place to start — especially on an account you didn't build yourself. Ask how something works, get a second opinion on a flow, or think through an approach before you commit to it.

Because the Copilot reads your live configuration, its answers describe your actual flows, data points, and APIs — not a generic example. That makes it the fastest way to learn an unfamiliar setup.

Explain existing configuration​

Ask how a journey is handled, what a specific flow, data point, or API does, or where something is used. The Copilot traces the real wiring — which flow triggers, which objectives it collects, which data points feed it, and which custom API sits underneath.

"How is 'where is my order' handled for this customer?" "What does the sku_id data point do, and which flows use it?" "How does freshdesk_create_ticket work — what does it send and what does it return?" "Which flows would trigger if a customer says they want to cancel?" "What data points depend on a selected order?"

Good for: onboarding to a new account, confirming your mental model before a change, or finding the source of a value the customer is seeing.

Review or audit a flow​

Ask for a quality review with concrete improvement suggestions. The Copilot points out gaps, fragile conditions, unreachable steps, or missing handoffs — but does not apply anything. You decide what to act on.

"Review the warranty flow and suggest improvements." "Audit this flow for anything that could be cleaner or could break." "Are there any dead ends in the refund flow where the customer gets stuck?" "Does the cancellation flow handle the case where the order already shipped?"

When you're ready to act on the feedback, hand the specific change to Build & change flows.

Plan an approach​

Ask for design direction before building. This is where to bring a fuzzy goal and let the Copilot help you shape it — including whether something should even be a flow at all.

"I want to support warranty eligibility — how should I set it up?" "Should delayed delivery be an FAQ or a flow?" "What's the cleanest way to collect an image and verify it before escalating?" "I need to route damaged-item claims differently from wrong-item claims — how should I structure that?"

A planning answer typically covers what to collect, where data comes from, where the conversation should branch, and when to hand off to a human — so you can turn it into a build request with confidence.

Getting better answers​

  • Name the specifics. "the warranty flow" and "the order_status data point" get precise answers; "the thing that checks orders" makes the Copilot guess.
  • Give the customer's words. For "how is this handled" questions, paste roughly what the customer would say — that's what actually decides which flow triggers.
  • Ask why, not just what. "Why would this flow not trigger for a returning customer?" surfaces the reasoning you'll need before changing anything.