> ## 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 Triage

> Deploy the entry point for new dispute and chargeback cases

The intake layer turns external events into a clean case record. It should be deterministic because downstream agents and workflows depend on consistent inputs.

## What It Does

The intake function:

* Receives a dispute case from a ticketing event, custom webhook, or payment processor event
* Creates or finds the internal case record
* Extracts required fields such as processor case ID, amount, currency, deadline, transaction ID, account ID, and reason text
* Validates that required fields are present
* Routes incomplete cases to an enrichment or escalation path
* Starts the main dispute handling workflow

## Recommended Components

| Need                             | Duckie component                   |
| -------------------------------- | ---------------------------------- |
| Receive ticket or webhook events | Deployment                         |
| Normalize case data              | Case validation workflow           |
| Fetch missing processor details  | App tool, custom tool, or MCP tool |
| Classify ambiguous reason text   | Reason classification agent        |
| Track analytics                  | Categories and attributes          |

## Flow

```mermaid theme={null}
flowchart TD
  Trigger["Ticket, webhook, or processor event"] --> Intake["Intake deployment"]
  Intake --> Validate["Case validation workflow"]
  Validate --> Required{"Required data present?"}
  Required -->|Yes| Main["Dispute handling workflow"]
  Required -->|No| Enrich["Fetch missing details"]
  Enrich --> Required
  Required -->|Still missing| Escalate["Slack escalation agent"]
  Main --> Classify["Reason classification agent"]
  Classify --> Route["Route by reason, deadline, and value"]
```

## Deployment Steps

<Steps>
  <Step title="Choose the trigger">
    Use a ticketing deployment when cases originate in a support system. Use a custom webhook when the payment processor or internal system should start the run directly.
  </Step>

  <Step title="Start in Testing mode">
    Create the deployment in **Testing** mode so you can review the extracted case record before live automation.
  </Step>

  <Step title="Call the validation workflow">
    Route the deployment to a workflow that checks required fields, normalizes names, and records missing data.
  </Step>

  <Step title="Add enrichment tools">
    Enable tools that can fetch transaction, account, processor, ticket, and CRM details.
  </Step>

  <Step title="Attach classification">
    Call a specialized classifier agent only after the case has enough context to classify reliably.
  </Step>
</Steps>

## Fields to Normalize

| Field               | Purpose                                                                                  |
| ------------------- | ---------------------------------------------------------------------------------------- |
| `case_id`           | Stable Duckie-side identifier for the dispute case.                                      |
| `processor_case_id` | External processor identifier used for lookup and submission.                            |
| `transaction_id`    | Payment or order reference used to gather evidence.                                      |
| `account_id`        | Account, merchant, or customer record connected to the case.                             |
| `reason_code`       | Processor reason code, when available.                                                   |
| `reason_summary`    | Human-readable reason text for routing and review.                                       |
| `response_deadline` | Latest safe date to act on the case.                                                     |
| `case_value`        | Amount at risk for prioritization.                                                       |
| `current_status`    | Intake, waiting for account, approval needed, submitted, won, lost, accepted, or closed. |

<Info>
  The exact field names can match your internal data model. The important part is that the workflow produces a stable, structured case object before agents begin judgment-heavy work.
</Info>

## What to Track

Use categories and attributes from the first deployment:

* Reason category
* Case value band
* Deadline risk
* Intake source
* Missing data type
* Automation path
* Final outcome

## Related Docs

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

  <Card title="Custom Webhooks" icon="plug" href="/deployments/custom-webhooks">
    Receive processor or internal events.
  </Card>

  <Card title="Categories" icon="folder" href="/tagging/categories">
    Track dispute reason categories.
  </Card>

  <Card title="Attributes" icon="tags" href="/tagging/attributes">
    Track deadline, value, and source attributes.
  </Card>
</CardGroup>