Conversations & Buyer Journeys

QueryBurst Answer Engine models buyer journeys as stateful, multi-turn conversations that branch. Each turn inherits everything that happened before it. Conversation state, turn order, the assistant's own answers, and branching decisions all become part of the context that shapes subsequent research and responses.

What is a buyer journey in Answer Engine?

A buyer journey is a stateful, multi-turn conversation.

For example:

"How can I stop projects slipping?"

then:

"Would project management software help?"

then:

"What are the best options?"

then:

"Trello sounds simplest. What would I lose versus the others?"

The important point is that the later questions have provenance.

Why Trello?

Because Trello entered the conversation earlier.

A standalone prompt such as:

"Best project management software vs Trello"

contains the comparison, but not the reason the comparison exists.

It is a snapshot from somewhere in the middle of a journey.

Isn't a buyer journey still hypothetical?

Yes.

Answer Engine does not claim that one modelled journey predicts the exact conversation a particular human will have.

But businesses have modelled customer behaviour, personas, funnels, and buyer journeys for decades for exactly this reason: you cannot predict every possible path.

The goal is not to model every human.

It is to model:

  • the customer types that matter
  • the problems they arrive with
  • the important journeys they may take
  • the meaningful decisions and forks along those journeys

Prompt tracking makes assumptions too.

It simply tends to hide those assumptions inside a fixed list of isolated prompts.

Do I need to know exactly what customers will ask?

No.

You cannot know every prompt a real customer will type.

Neither can a prompt tracker.

Answer Engine asks a different question:

Can we model the important customer types and plausible journeys well enough to investigate how AI behaves across them?

That is much closer to traditional buyer-journey modelling than keyword forecasting.

How is a buyer journey different from assigning prompts to funnel stages?

A list such as:

  • Awareness prompt
  • Consideration prompt
  • Comparison prompt
  • Transactional prompt

can represent different stages of a funnel.

It does not necessarily represent a journey.

If every prompt runs independently, the comparison prompt knows nothing about the awareness answer.

The transactional prompt does not know which products were discovered during consideration.

Nothing has actually travelled through the funnel.

A prompt set can describe stages of a journey without modelling the journey itself.

Why does conversation state matter?

Because later questions often make no sense without it.

Consider:

"Which one is best for our team?"

There is no complete question there.

Which one of what?

What team?

What criteria matter?

In a real AI conversation, those answers may already exist in the preceding turns and persistent user context.

The visible prompt can therefore be extremely short while triggering very specific research.

That is one of the central ideas behind Answer Engine and QueryBurst’s definition of AI visibility:

the prompt is not the whole input.

Does the order of questions matter?

Yes.

A multi-turn conversation is not just a long prompt chopped into smaller pieces.

At each turn, the model receives the state created by what happened before: the user's previous questions, the model's previous answers, products or concepts that entered the conversation, criteria that became important, and decisions or objections that emerged along the way.

So changing the order can change the journey.

For example:

"Which CRM is best for our team?" → "What are the cancellation terms?"

may lead somewhere different from:

"Which CRM has the most flexible cancellation terms?" → "Which is best for our team?"

In the first journey, the model may establish a preferred shortlist before cancellation becomes a criterion. In the second, cancellation flexibility can shape the research and shortlist from the beginning.

Order is part of the context.

Does the assistant's previous answer count as context?

Yes.

In a multi-turn conversation, context is created by both sides.

The next user message depends not only on what the user previously said, but on what the assistant previously told them.

For example:

"What CRM should I look at?"

The assistant recommends HubSpot and Pipedrive.

"Which one is easier to cancel?"

That second question only exists because the assistant introduced those products in the first place.

A single mega-prompt can include all the user's requirements, but it cannot naturally reproduce the intermediate model responses that shape later questions unless you pre-script the entire conversation in advance.

The assistant's answers are part of the journey state.

Is that really different from putting all the requirements into the first prompt?

Yes.

You can certainly write one large prompt containing everything you think matters. That may produce a useful answer.

But it is not equivalent to a conversation.

A single prompt makes all of the supplied context available at once. A conversation introduces information progressively, and the model's own answers become part of the state that influences later turns.

That matters because the journey may discover things you did not put into the original prompt.

A product might enter the shortlist.

The model might raise a trade-off.

The user might react to it.

A new criterion might become important.

The next question can then depend on that newly created state.

If you put the entire journey into the first message, you have to predict all of those intermediate states in advance.

Isn't the conversation eventually just sent to the model as context anyway?

Yes. The model ultimately receives tokens representing the conversation.

But how those tokens got there matters.

A multi-turn conversation preserves the sequence and roles that created the state:

user → assistant → user → assistant → user

That is different from flattening the assumed end-state into one synthetic user message.

The assistant responses were actually generated. Products may have entered the conversation. Criteria may have emerged. The user's next question can refer to those outputs. Different branches therefore contain genuinely different histories.

The distinction is not "context window versus no context window."

It is evolved state versus prewritten state.

Can the same question produce different answers depending on how the buyer reached it?

Yes.

Consider the identical question:

"Which one should I choose?"

On one branch, the previous discussion may have focused on price.

On another, security.

On another, cancellation terms.

The literal message is unchanged, but the conversation state behind it is different.

That can change the model's initial position, research path, retrieved evidence, and final recommendation.

The path to the question is part of the input.

What happens if a buyer takes a different path?

You branch the conversation.

At any turn, you can create alternative downstream paths.

For example, after a CRM recommendation:

Branch A

"Which ones offer free trials?"

Branch B

"Which has the most flexible cancellation terms?"

Both branches inherit everything that happened before the split.

After that, they evolve independently.

In our own testing, the cancellation branch materially changed the CRM recommendation because new evidence and criteria entered the conversation.

Can branches have branches?

Yes.

A journey is effectively a graph rather than a linear transcript.

Branches can split again whenever a meaningful alternative path appears.

This allows a relatively small number of personas and starting journeys to represent a much larger space of plausible customer behaviour.

Can one persona have multiple buyer journeys?

Yes — and normally it should.

A persona describes the person, not one predetermined path through a buying decision.

The same buyer might:

  • begin with a broad problem
  • start by comparing known products
  • arrive with a recommendation from a colleague
  • begin with a specific objection
  • investigate a completely different use case

Each can be modelled as a separate journey for the same persona.

That is another reason not to bake the journey into the persona.

One person can take many journeys. You should not need a new persona for each one.

Do I need to decide every branch before I start?

No.

A branch represents an alternative that becomes interesting at a particular point in the conversation.

You might discover during analysis that an answer introduced a trade-off worth exploring, or realise later that a buyer could plausibly have reacted differently.

You can branch from that point and explore the alternative path.

Buyer-journey modelling is iterative. You do not need to predict the entire graph before the first message is run.

What if a real user starts a new ChatGPT conversation instead?

That is another plausible journey.

Answer Engine is not claiming that every buyer maintains one endless chat.

You can model journeys that begin with little or no previous conversation state, journeys that begin deep in the funnel, and journeys that inherit substantial context.

The objective is to model meaningful behavioural possibilities rather than assert that there is one canonical conversation.

Doesn't choosing the journey introduce researcher bias?

Yes. Any modelled journey reflects assumptions about the customer and the questions worth investigating.

Prompt sets do too.

The solution is not to pretend those assumptions disappear. It is to make them explicit and model multiple plausible alternatives.

Use customer research, sales conversations, product knowledge, support data, search behaviour, surveys, or real conversation data where available to inform the journeys. Then branch where meaningful alternatives exist.

Answer Engine is not designed to produce a statistically representative transcript of every customer. Our position on why real-user data does not automatically establish representativeness applies equally here — any modelled journey reflects assumptions about the customer.

It is designed to make plausible customer journeys inspectable.