Route account expansion evidence to a measurable owner action

Define candidate types around needs that a reviewer can confirm. Examples include a customer-stated request for another department, repeated limits on an approved production workflow, and an existing request for a capability absent from the current entitlement. Keep observation, need_hypothesis, and commercial_validation as separate fields. Never infer budget, authority, willingness to buy, or commercial urgency from event frequency. A repeated behavior is a reason to ask a question, not a qualified expansion deal.

Use account health and renewal context to route work, not to manufacture a need. If an account has an unresolved support escalation, send the candidate to the CSM for sequencing before AE review. If renewal discussions are active, name the existing commercial owner to avoid parallel approaches. Keep renewal dates out of the expansion trigger itself. Exclude automated outreach, quoting, entitlement changes, discount proposals, customer-record writes, and automatic opportunity creation from the agent's authority.

Create candidate_id, account_id, product_tenant_ids, legal_entity_id, contract_id, contract_version, entitlement_version, product_code, included_capability, contracted_limit, limit_unit, limit_period, current_allocation, observed_consumption, and entitlement_review_status. Store source_document_url, clause_location, effective_at, and reviewer_id with the contract interpretation. Record need_type, need_statement, evidence_ids, counterevidence_ids, alternative_explanation, unknowns, and expires_at. Keep legal entity and product tenant distinct so that a parent company's contract does not silently cover every subsidiary.

For each observation, retain event_name, event_schema_version, group_id, observed_at, window_start, window_end, source_updated_at, numerator, denominator, and instrumentation_status. For stakeholders, store existing_contact_id, role_claim, role_source_id, role_confirmed_at, and role_status. For routing, store csm_owner_id, ae_owner_id, routing_reason, accepted_by, accepted_at, next_action, due_at, completion_proof, disposition, retracted_at, and retraction_reason. These fields form your internal contract. Do not assume vendor data arrives with the same meanings or that a missing role is a negative fact.

Read a permitted subset of company, deal, and activity properties. HubSpot's object API supports selected properties and associated record IDs. When you use batch reads, retrieve associations separately because the batch read endpoint does not support the associations parameter. Store the IDs and timestamps that support the account packet. Accept this step only when the CSM can open each source under their normal permissions and every observation resolves to one authorized account or an explicit quarantine state.[1]

Segment Group associates individual users with group IDs, and a user can belong to multiple groups. Segment Track supports context.groupId for account attribution. Use the group attached to the observed action, plus your approved tenant mapping, instead of copying a user's latest group across all their events. In a hypothetical case, user-6 works in tenant-12 and tenant-18. Count the production limit event only against tenant-12 when its event identity and entitlement mapping support that assignment.[3][4]

Compare the proposed capability with the reviewed entitlement catalogue and executed contract version. Ask contract operations to resolve amendments, pooled allocations, subsidiary coverage, and terms that do not map cleanly to a product setting. Treat missing entitlement evidence as review_required. Do not translate a product error message into a purchasing obligation. Your acceptance check is a candidate showing the relevant included capability or limit, its unit and period, and the reviewer-approved source that establishes the current scope.

For a hypothetical account-28, observed_consumption=96, contracted_limit=100, limit_unit=active seats, and current_allocation=100 describe capacity context. They do not establish additional demand. If another 25 seats already exist in an approved pool, route an allocation review to CS rather than an expansion candidate to sales. If a capability is included but disabled, route enablement or support. If contract scope is disputed, stop commercial routing until the accountable reviewer resolves the disagreement.

Use only approved event definitions and customer-stated request records. Segment Track records named actions and their properties. Build complete, comparable observation windows and exclude test tenants, automation users, migration intervals, and declared instrumentation outages according to your data policy. Present the raw observation separately from the proposed need. For a blocked workflow, name the workflow and observed constraint. Include plausible noncommercial explanations such as configuration, temporary testing, or an allocation that the entitlement reviewer has not yet confirmed.[4]

Configure OpenAI Agents SDK output_type to return structured candidate fields rather than an unrestricted sales narrative. Require evidence IDs for observations and a disproof_condition for every hypothesis. A hypothetical output can say 'The operations team may need access for a second department. An approved account note records that request. Withdraw if the request refers to users already included in the current allocation.' Accept this step only when the reviewer sees the exact request, its date, and the unanswered commercial questions.[5]

Use existing authorized contacts and approved notes to map the workflow user, department owner, current sponsor, commercial decision owner, and procurement contact where evidence exists. Give each role its source and last confirmation date. Do not label a frequent user as the budget holder. If the commercial decision owner is unknown, make stakeholder confirmation the next action rather than inventing a person. Do not add external enrichment to fill the gap. The CSM owns account context until commercial routing is accepted.

Set explicit route states such as cs_review, ae_review, accepted, deferred, rejected, and retracted. Send allocation and enablement questions to CS. Send a validated additional-scope question to the named AE only after the CSM confirms the context. If an existing opportunity covers the same product and need, attach the candidate for that owner's review instead of opening another route. Accept this step when the AE can acknowledge or reject ownership with a reason and the CSM sees that decision in the same queue.

Show the AE an evidence card with account identity, need statement, included scope, remaining uncertainty, stakeholder map, source links, CS review, and expiry. Ask the AE to choose a bounded action. A hypothetical action is 'Review the approved department request with the CSM by 2026-11-04 and record whether additional scope exists.' Its completion proof is the reviewed need statement and disposition, not a claim that the owner looked at the card. Leave any customer interaction to the existing approved human process.

Keep action drafts outside the CRM until a human accepts them. HubSpot task fields support subject, body, due date, owner, and record associations. If you later connect task creation through n8n, require human review of the exact tool parameters, with denial canceling execution. Recheck candidate expiry, routing owner, and duplicate action keys before the accepted write. Never make approval of an internal task authorize an opportunity, price change, or customer message. Acceptance requires one approved action to produce exactly one recorded task.[2][6]

Handle Already entitled, Temporary load test, Shared user identity, Service incident, Existing opportunity, and Withdrawn request as named negative cases. Already entitled becomes an enablement question or a rejection, not an upsell. Temporary load test removes the affected event evidence. Shared user identity quarantines the account assignment. Service incident keeps CS in charge of sequencing. Existing opportunity routes to its owner without duplicating the candidate. Withdrawn request retracts the need hypothesis even if product activity remains high.

Version candidates and expire unreviewed evidence on a policy-defined schedule. When a new amendment, allocation correction, or customer clarification defeats the hypothesis, mark it retracted and show the reason beside the old card. Notify the internal owner through the approved queue and invalidate pending task approval. Keep the audit history and human dispositions. If the AE already created an opportunity through their own process, ask that owner to reconsider it. Do not autonomously delete pipeline or rewrite a forecast because the evidence changed.

Measure entitlement resolution as reviewed candidates with a confirmed current entitlement interpretation divided by all reviewed candidates, expressed as a percentage per review cycle. Measure need validation as candidates whose account need the CSM confirms divided by candidates reviewed by CS. Keep confirmed need separate from AE qualification. Measure owner acceptance as routed candidates explicitly accepted by the intended AE divided by candidates routed to AE review. Report deferred and rejected reasons alongside the percentage rather than treating every nonacceptance as a failure.

Measure on-time action completion as accepted actions due in the reporting period with required proof recorded by due_at, divided by all accepted actions due in that same period. Report the percentage and the number of due actions. Measure routing latency as total hours from CS validation to recorded AE disposition divided by candidates with both timestamps. Measure retraction latency as total hours from receipt of disqualifying evidence to visible retraction divided by retracted candidates. Use the same reporting cohort for each latency numerator and denominator, and report pending-review age separately. Track duplicate rate as duplicate candidate cards divided by generated cards in the same cohort. Segment results by need type. Do not equate usage growth, accepted tasks, or generated pipeline with attributable revenue.

Pilot one account segment in shadow mode using a small approved catalogue of need types. Include negative cases and accounts with pooled entitlements. Have CS Operations review identity and routing, contract operations review entitlement interpretation, and an AE manager review next-action quality. Promote the queue to visible use only after those owners accept their boundaries. Keep a manual account-planning process available. Expand need types separately so that a working seat-capacity rule does not imply approval for every product signal.

Give the GTM engineer responsibility for pausing generation and CS Operations responsibility for candidate retraction. Stop routing after cross-account evidence, unsupported entitlement claims, or an owner assignment defect. Cancel pending approvals and mark affected candidates unavailable. Let CS and AE owners decide the disposition of already accepted work. Preserve source versions and reasons for rollback. Resume after the responsible owner repairs the mapping, entitlement, or policy input and confirms that the triggering negative case no longer reaches commercial review incorrectly.