Integration and automation#

Once a customer hits submit, the claim doesn't just sit in a database waiting for someone to look at it. Karla runs a per-brand automation layer that takes the structured claim, routes it to your tools, and — when your rules allow it — closes it automatically in your shop.

Claims, anywhere you want them#

Every claim can reach your helpdesk in one of two ways:

• Native integrations — connect Zendesk, Gorgias, Dixa, Kustomer, or Intercom directly in the Karla portal. Karla authenticates with your instance and creates tickets with the right fields, attachments, and customer threading. No native helpdesk? An email fallback sends claims to your support inbox. See Helpdesk integrations.
• Webhooks — point Karla at any HTTPS endpoint and receive the structured claim payload described in Data processing. You map it to your helpdesk, or use a connector. See Webhooks.

Either way, your agents see a properly populated ticket — photos, affected items, order context, resolution preference — not a JSON dump.

Claim automation — rule-based refunds and replacements#

For qualifying claims, you don't need an agent in the loop at all. Karla can issue refunds and trigger replacement orders directly in your shop the moment a claim matches your rules.

This is self-serve and per merchant. In the portal under Settings → Claim Automation, you build an ordered rule set:

• Logic checks on claim reason, resolution preference, claimed value, and shipment status — combined with AND logic inside each rule.
• Automate or Manual actions per rule, evaluated first-match-wins from top to bottom.
• Notification mode — still create a helpdesk ticket when Karla automates, or stay silent and resolve only in your shop.
• Platform safety gates — stock, address, duplicate-order, and shop errors can still block automation even when a rule matches.

Refund vs replacement is not chosen in the rule — it follows the customer's resolution preference on the claim. Your rules decide whether Karla may act automatically.

The goal is to get the predictable share of claims off your team's plate without giving up control: you define the logic, Karla enforces it, and anything that doesn't match (or fails a safety gate) lands with your agents.

Custom transformations#

Beyond self-serve claim automation and helpdesk routing, Karla can reshape claims for specialized operations — often set up with your account team.

Claims rarely fit one shape. The same submission might need to become a ticket in your helpdesk, a row in your warehouse, a refund in your shop, and a PDF for a carrier dispute — all at once. The automation layer takes care of that fan-out.

Common extensions merchants ask for:

• DOR (Damage / Operations Report) documents generated from claim data for carrier disputes or internal audits. The carrier affidavit PDF for not-received claims is self-serve — turn it on per helpdesk in Helpdesk integrations.
• Custom payload shapes for non-standard helpdesks, internal ticketing systems, or BI pipelines.
• Conditional routing — send specific claim types to specific queues, brands, regions, or warehouses beyond the portal rule builder.
• Enrichment — combine the claim with order, shipment, or customer context before forwarding it on.

If you can describe what you want to happen when a claim comes in, we can almost certainly wire it up. Talk to us.

Where to next#

• Claim automation — configure rule sets, safety gates, and notification mode in the portal.
• Helpdesk integrations — connect Zendesk, Gorgias, Dixa, Kustomer, or Intercom, or route claims via webhooks.
• Data processing — the claim payload itself, and where claims live in Karla.
• Shop connection — refund and replacement prerequisites.
• Integrate in your shop — embedding the resolve widget on your domain.
• Portal → Resolve — the Claims view and analytics.