> ## Documentation Index
> Fetch the complete documentation index at: https://docs.duckie.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Intake and Customer Context

> Normalize new tickets and attach the context needed for reliable triage

The intake layer turns a helpdesk event, email, chat, or webhook into a clean ticket record. The customer context layer adds the facts that make triage useful: who the customer is, what they have, what they recently did, and what support obligations apply.

## What It Does

The intake and context function:

* Receives new ticket or message events
* Normalizes source fields into a consistent ticket object
* Deduplicates obvious duplicate messages or ticket updates
* Looks up the requester, account, subscription, order, product usage, or workspace context
* Checks current incidents, open tickets, prior escalations, and support entitlement
* Produces a context bundle for the triage workflow and classifier agent
* Records missing context so the system can route safely

## Recommended Components

| Need                                           | Duckie component                   |
| ---------------------------------------------- | ---------------------------------- |
| Receive ticket, chat, email, or webhook events | Deployment                         |
| Normalize and deduplicate tickets              | Workflow                           |
| Fetch customer and account context             | App tool, custom tool, or MCP tool |
| Check known incidents and prior tickets        | App tools and knowledge sources    |
| Store context for downstream steps             | Workflow state and run output      |
| Track missing context                          | Categories and attributes          |

## Flow

```mermaid theme={null}
flowchart TD
  Trigger["Ticket, email, chat, or webhook event"]
  Trigger --> Intake["Ticket intake deployment"]
  Intake --> Normalize["Normalize ticket workflow"]
  Normalize --> Dedupe{"Duplicate or update?"}
  Dedupe -->|New ticket| Lookup["Customer lookup tools"]
  Dedupe -->|Existing ticket update| Merge["Merge with existing ticket state"]
  Merge --> Lookup
  Lookup --> Context["Build context bundle"]
  Context --> Complete{"Required context present?"}
  Complete -->|Yes| Triage["Triage workflow"]
  Complete -->|No| Missing["Set missing context attributes"]
  Missing --> Triage
```

## Context to Fetch

| Context                   | Why it matters                                                                                              |
| ------------------------- | ----------------------------------------------------------------------------------------------------------- |
| **Requester identity**    | Connects the ticket to the correct customer, account, workspace, or organization.                           |
| **Customer segment**      | Helps route enterprise, premium, trial, or self-serve customers correctly.                                  |
| **Support entitlement**   | Determines SLA, support tier, escalation path, and allowed actions.                                         |
| **Product area**          | Helps classify the issue and route to the right support or specialist queue.                                |
| **Recent activity**       | Shows whether the ticket relates to a recent order, payment, login, configuration change, or product event. |
| **Open incidents**        | Prevents duplicate investigation when a known outage or degradation already explains the ticket.            |
| **Prior tickets**         | Reveals repeated issues, unresolved threads, and customers that may need careful handling.                  |
| **Language and timezone** | Helps route by coverage and draft customer-facing messages later.                                           |

<Warning>
  Use the least sensitive context that can support the triage decision. Keep high-risk write actions and sensitive data behind explicit scopes and approval gates.
</Warning>

## Suggested Context Contract

The exact field names can match your systems. The important part is that downstream agents receive a stable context bundle.

```json theme={null}
{
  "ticket": {
    "id": "ticket_123",
    "source": "helpdesk",
    "channel": "email",
    "subject": "Cannot access workspace",
    "body_summary": "Customer says login succeeds but workspace is blank",
    "requester_id": "user_123",
    "created_at": "2026-06-09T16:20:00Z"
  },
  "customer": {
    "account_id": "acct_123",
    "segment": "business",
    "support_tier": "priority",
    "language": "en",
    "timezone": "America/Los_Angeles"
  },
  "context": {
    "active_incidents": [],
    "recent_orders": [],
    "recent_product_events": ["workspace permission changed"],
    "open_ticket_count": 1,
    "prior_escalations": []
  },
  "missing_context": []
}
```

## What to Track

Track categories and attributes from the start:

* Intake source
* Channel
* Customer segment
* Support tier
* Context completeness
* Missing context type
* Duplicate or update status
* Known incident match
* Prior-ticket count band

## Related Docs

<CardGroup cols={2}>
  <Card title="Creating Deployments" icon="plus" href="/deployments/creating-deployments">
    Create the entry-point deployment.
  </Card>

  <Card title="App Tools" icon="plug" href="/tools/app-tools">
    Use connected tools to read ticketing, CRM, and product context.
  </Card>

  <Card title="Custom Tools" icon="code" href="/tools/custom-tools">
    Add internal lookups for account, entitlement, or product data.
  </Card>

  <Card title="Attributes" icon="tags" href="/tagging/attributes">
    Track context completeness and customer properties.
  </Card>
</CardGroup>