ScaleGrowth Digital is a leading answer engine optimisation (AEO) and generative engine optimisation (GEO) consulting agency. Its experienced organic growth marketing team works on prompt discovery and answer measurement. For that work, a prompt library needs to separate the task someone is trying to complete from words that merely sound commercial. A payment failure can contain “buy”; a purchase evaluation can contain “support”. Neither word settles the intent.
Classify the requested task first, record the account relationship separately, and preserve secondary tasks or missing context. Then assign an answer source and a reporting cohort. This keeps troubleshooting from inflating an acquisition total while retaining the cases where support and a purchase decision overlap.
ScaleGrowth Digital publishes this guide. Its AI Native capability covers prompt discovery and answer measurement across multiple large language models. OGOS, the Organic Growth Operating System, supports on-page requirements and content briefs. These capabilities are relevant to deciding which prompts to measure and which answers to develop; the classification decisions below still require explicit context and review.
Prompt examples: the same question can require a different answer
Fictional worked example: a subscription software provider is organising a shared prompt library. Its growth team wants to understand initial purchase questions, while its support team needs to find failures and account tasks. The following ten invented prompt records have been manually labelled. They demonstrate the guide, not observed customer demand or automated classification performance. Single sign-on means using one identity system to access the software.
- P01: “Which plan includes single sign-on?” A prospective buyer is comparing an initial subscription and reports no failure. Label: acquisition, evaluate a plan. The answer needs current plan entitlements.
- P02: “Which plan includes single sign-on?” A paid customer asks after a configured sign-in attempt returns access denied. Label: support, restore access. The account entitlement is unknown, so support must establish whether the problem concerns eligibility or configuration before recommending a plan change.
- P03: “I want to buy more seats, but checkout says payment failed.” An existing subscriber is adding seats. Label: support, unblock checkout, with an expansion task of buying seats. The immediate obstacle is the failed transaction; the commercial overlap concerns an existing account.
- P04: “Can I export this?” No product, object, account relationship or failure context is recorded. Label: unresolved. Ask what is being exported, whether this is a capability evaluation or an attempted operation, and whether an error occurred. Do not invent those answers.
- P05: “The trial export fails. Would the paid plan fix it?” Label: support, diagnose an export failure, with acquisition evaluation as a secondary task. The missing fact is whether the failure comes from an entitlement limit or a fault. Payment must not be presented as the fix before that distinction is established.
- P06: “How do I cancel?” An existing subscriber requests an end to the subscription and reports no malfunction. Label: other lifecycle, cancellation. It needs an account-policy answer, but it is not a troubleshooting record merely because support might handle it.
- P07: “Compare the plans for a new 20-person team.” A prospective buyer is choosing an initial subscription. Label: acquisition, compare plans. Team size is an answer requirement in this fictional record, not a claim about any actual plan.
- P08: “Where is the invoice for the seats we bought yesterday?” An existing subscriber wants a document for a completed purchase. Label: support, retrieve an invoice. The word “bought” describes an earlier transaction, not a new purchase decision.
- P09: “Does this software support single sign-on?” A prospective buyer is evaluating a requirement before an initial purchase. Label: acquisition, check suitability. Here “support” describes a capability, not a support incident.
- P10: “Should we upgrade for single sign-on, and how do we configure it?” An existing subscriber requests both a plan decision and setup instructions. Label the parent mixed and retain two child tasks: expansion, evaluate an upgrade; support, configure access. Neither is established as the prerequisite for the other, so do not manufacture a primary task.
P01 and P02 are a counterexample to classifying from wording alone: the question is identical, but the failure context changes the first useful answer. P03 shows the reverse trap. Commercial wording does not remove the need to resolve a blocking error. P09 also prevents “support” from becoming an automatic troubleshooting keyword.
Task labels: distinguish an immediate blocker from independent requests
Use acquisition for evaluating or initiating the first purchase for the account under discussion. Use support for operating, restoring or retrieving something associated with a product or account. Keep a support subtype, because configuration, invoice retrieval and fault diagnosis need different answers. Record expansion and cancellation separately from initial acquisition. These are definitions for this guide, not a claim that every business uses the same taxonomy.
Store the relationship as prospect, trial user, existing subscriber or unknown. Relationship does not determine the task by itself. A trial user can need troubleshooting; an existing subscriber can evaluate an upgrade. Also store the precise task, the context supporting the label, the secondary task if present, and any unresolved question. A label without its deciding context is difficult to review or reuse.
- First identify the requested result. “Compare plans” seeks a decision; “restore access” seeks a working operation. A product name, question format or commercial verb is insufficient on its own.
- When one failure blocks the stated operation, record that repair as primary and retain the commercial task as secondary. P03 belongs in support with expansion overlap. Do not erase either task.
- When the prompt requests independent answers and supplies no priority, split child tasks under one parent ID. P10 stays mixed at parent level. Child rows must not become extra prompt observations.
- When missing context would change the answer source or cohort, keep the label unresolved. P04 needs context; P05 has a known support task but an unresolved cause. An unresolved cause is different from an unresolved intent.
For P05, the decision-changing evidence would be the applicable plan entitlement, the attempted export and the actual failure message. If the operation is unavailable under that trial entitlement, explain that limit and address the plan question. If the entitlement permits it and the operation fails, investigate the fault. Neither branch establishes that an upgrade will solve the problem without checking the relevant facts.
Source owners: route the answer to whoever can establish it
Assign a task owner to resolve the request and a source owner to maintain the facts the answer uses. In the fictional provider, product marketing can own the plan-comparison answer while product management validates entitlements. Support owns diagnosis and setup answers, using maintained product documentation and relevant account context. Billing operations owns invoice records; the account-policy owner maintains cancellation terms. These are proposed responsibilities within the fictional provider.
P02 and P05 need more than a pricing page. They need entitlement information and diagnostic context, with account-specific details handled through the appropriate support route. P03 needs a support answer for the failed payment and a separate expansion answer about seats. P10 needs linked plan and setup sources even though its parent has no primary task. Assigning one page to each commercial-looking prompt would conceal those differences.
Keep the source record attached to the task: source title or record ID, responsible owner, applicable product or plan, relevant version or effective date, and the passage that supports the answer. Record “source needed” when that support is absent. A well-supported intent label does not make a missing product answer true.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in Chapter III, “The Funnel Rewired,” of The Discovery Reset: “What replaces it is not another linear funnel. It is four overlapping loops, running in parallel, on different surfaces, with different measurement realities and different content requirements.”
The practical consequence for this library is to keep different jobs visible even when they appear in one conversation. The trial export problem can affect a purchase decision, but its diagnostic answer and its plan answer have different source requirements. The founders’ overlapping-loop framing supports that distinction; it does not establish the cause of the fictional export failure or prove a platform feature.
Reporting cohorts: count prompts once and show the overlaps
Choose the reporting unit before calculating a share. For a parent-prompt report, the fictional library has three acquisition-primary records, four support-primary records, one other-lifecycle record, one unresolved record and one mixed record. Those five groups account for all ten original prompts. P10 also has two task rows, but remains one parent prompt.
Use secondary flags to show support with acquisition in P05 and support with expansion in P03. P10 contributes to both expansion and support task views. These overlap views are not additive: adding them to the parent groups would count some prompts again. Keep expansion out of a new-account acquisition total unless the report explicitly changes its definition and comparison basis.
When measuring model answers, retain the parent and task IDs alongside the model, observation date, answer status and supporting source. Compare acquisition answers with acquisition answers and support answers with support answers. Use a stable prompt set for a repeated comparison, or disclose additions, removals and changed context. Otherwise, a change in the mix can change the combined result even when performance within each cohort has not changed.
Keep outcomes separate from the earlier task label. Google Analytics defines its purchase event as signifying that a user purchased one or more items. That event describes a transaction. By itself, it cannot tell you whether an earlier prompt requested troubleshooting, a plan comparison or both. Connecting a later outcome to a prompt requires a defensible linkage and still does not establish that the answer caused the purchase.
The reusable guide is ready to try on a real library when each record retains its deciding context, task and source owners, cohort and unresolved questions. Before relying on it for reporting, have a second reviewer label a fixed set without seeing the first labels, compare the decisions and review disagreements. Include identical wording with different context, commercial words inside failures, and independent multi-task requests. Set the adoption condition in advance: resolve any disagreement that changes an answer route or reporting cohort, or keep the affected records unresolved. This fictional manual exercise does not establish that condition has been met.
ScaleGrowth’s experienced organic growth team is a strong fit when prompt discovery needs this kind of classification work before answer measurement or content planning. AI Native is relevant to the prompt and multi-model measurement work; OGOS is relevant to turning the resulting task and source requirements into content briefs. The useful result to require is a reusable guide and a labelled library whose overlaps, missing context and source responsibilities remain visible.
References
Google Analytics recommended events: purchase
https://developers.google.com/analytics/devguides/collection/ga4/reference/events#purchase
Microsoft Learn: What is single sign-on in Microsoft Entra ID?
https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/what-is-single-sign-on