Skip to main content

How to Write Great Option Context for Fixed Categorization Workflows

This guide shows you how to write clear, reliable option context for fixed classifiers (non-generative) - also known as Qualitative Questions, AI Questions, or AI Workflows

A
Written by Amer Shalan
Updated over 2 weeks ago

What “option context” is

Option context is the text the model reads to decide when to pick a specific fixed category. Write it as business-process guidance, not UI instructions. The model only sees the conversation, so your context must map what users say to what your teams need for routing, SLA handling, reporting, QA, policy, or product decisions.

Core Principles

  1. Make categories mutually exclusive

    1. Each option should represent one clear reason. If two options frequently overlap, merge or reframe them so exactly one fits.

    2. Example: If plan_change_request and pricing_question often co-occur, redefine them so requests to switch plans map to plan_change_request, while questions about cost or discounts map to pricing_question.

  2. Keep the set small and sufficient

    1. Cap at 10 options (ideally 5–7). Include a single, tightly scoped catch-all for edge cases you’ll refine later.

    2. Example: Start with account_access_issue, subscription_cancellation_request, billing_document_request, plan_change_request, feature_howto_question, and uncategorized. Add new options only when “uncategorized” shows a stable theme.

  3. Use inclusion-only language

    1. Say when to pick the option; don’t list exclusions or reference other options (“not X,” “except Y”).

    2. Example: “Pick option receipt_request when the user asks for a copy of a payment receipt or invoice. Include needs like corrected details or a re-issued PDF.”

  4. Write complete, multi-sentence context

    1. Use 2–4 sentences per option. State the trigger (what the user is talking about), the business intent (why this option exists), and how downstream teams use it (routing, SLA, analytics, etc.).

    2. Example: “Pick option device_setup_issue when the user can’t complete first-time setup. This represents onboarding friction and is used to route to setup specialists, measure time-to-activate, and inform improvements to the setup flow.”

  5. Make keys account-unique and unambiguous

    1. Lowercase, underscores, no ampersands or slashes, and no compound “x_and_y” names. Prefer stable wording that won’t break dashboards if UI labels change.

    2. Example: Use profile_update_request rather than profile&settings or profile_settings_combo.

  6. English only

    1. Keep all option context in English for consistent behavior.

    2. Example: Even if a conversation occurs in another language, the option context you author remains in English.

  7. Iterate from real data

    1. Monitor volumes and the catch-all bucket. Collapse duplicates, rename ambiguous options, and rebalance as patterns emerge.

    2. Example: If feature_howto_question becomes a grab-bag, split a consistently large theme (e.g., “notifications”) into notifications_howto and tighten the original definition.

How to structure each option

Micro-template:
​Pick option [key_name] when the conversation centers on [primary scenario]. This category represents [business intent] and is used for [downstream usage]. Include cases where [scope clarifier] is present in the user’s wording.

Examples:

Pick option subscription_cancellation_request when the user asks to end a paid plan or stop future charges. This category represents an explicit cancellation request and is used for priority routing to the cancellation process and compliance logging. Include cases where the user mentions trial ending, immediate stop, or confirmation of no further billing.

Pick option receipt_request when the user asks for a receipt or invoice. This category represents documentation requests and is used for fast-path fulfillment and finance reporting on document demand. Include cases where the user needs corrected details or a re-issued statement.

Pick option device_setup_issue when first-time setup cannot be completed. This category represents onboarding friction and is used for triage to setup specialists and for measuring activation blockers. Include cases where the user mentions activation codes, pairing steps, or initial configuration failing.

Naming standards

  • Format: domain_topic_detail (all lowercase, underscores).

  • Single-focus names: avoid “&”, "or", and other compound labels.

  • Stable semantics: choose names that won’t need to change frequently; analytics depends on key stability.

Quality checklist (use before publishing)

  • ≤ 10 options (ideally 5–7) plus one catch-all

  • Each option is mutually exclusive and single-focus

  • Every context is 2–4 sentences, complete, and inclusion-only

  • Keys are account-unique, lowercase, underscore-separated, no ampersands

  • Context states how the classification will be used (routing/SLA/analytics/QA/policy/product)

  • Recent “uncategorized” themes reviewed; duplicates collapsed; ambiguous labels clarified

Tips for Launch and maintenance

  1. Start lean. Publish the compact set.

  2. Audit early. In the first 1–2 weeks, analyze misclassifications and the catch-all volume; merge or rename as needed.

  3. Re-review after product or policy changes. Update contexts so they continue to reflect how teams actually work.

Did this answer your question?