Claim automation#

What you need#

Before turning automation on:

• Resolve enabled on your Karla package.
• Shop connected with refund and replacement endpoints exposed — Karla acts in your commerce platform when a rule matches. See Shop connection.
• Portal admin access — only admins can view and edit Claim Automation settings.
• Optional helpdesk integration — useful when you want agents notified even after an automated resolution. See Helpdesk integrations.

How a claim moves through automation#

When a customer submits a Resolve claim, Karla evaluates your rule set against the structured claim record — reason, resolution preference, claimed value, shipment status, and the rest of the payload described in Data processing.

Customer submits claim
  → Is claim automation enabled?
      No  → Manual handling (helpdesk ticket per your integration)
      Yes → Walk rules top-to-bottom
              → First rule where ALL conditions match:
                    refund   → Issue a refund in your shop
                    reorder  → Create a replacement order in your shop
                    automate → Refund or reorder in your shop (per customer preference)
                    manual   → Stop — manual handling
              → No rule matched → Manual handling
  → Safety gates may still override automation (see below)
  → Optional helpdesk notification (per your notification mode)

A matched rule's action decides the outcome:

Refund and Reorder force the outcome regardless of any preference — use them when you only ever offer one outcome. Automate follows the refund or reorder preference recorded on the claim — which is not always one the customer actively picked: claims submitted through the Resolve widget always carry a preference, even when the picker is hidden (see Customer resolution preference for the defaults). A claim with no recorded refund/reorder preference — for example one created through another channel, or a keep_with_reward choice — has no automated path under Automate and falls back to manual handling. You pick which options customers can choose under Resolve → Features → Resolution options in the portal — refund and reorder are offered by default, keep with reward is opt-in.

Configure rules in the portal#

In the Karla portal, open Settings → Claim Automation.

Master controls#

Notification mode options:

• Notify — create an outcome ticket in your helpdesk so agents see what Karla did (recommended when you want an audit trail alongside automation).
• Silent — resolve in your shop only; no ticket for automated outcomes.

Rule sets#

Rules are ordered. Karla evaluates them from top to bottom and stops at the first match. Reorder rules with the up/down controls when priority matters.

Each rule has:

• Action — Refund, Reorder, Automate, or Manual
• Conditions — one or more checks; all must match (logical AND)

Use Add rule and Add condition to build your set. A claim that matches no rule is handled manually — automation is strictly opt-in per matching rule.

Condition fields and operators#

Each condition compares one claim attribute to a value you set.

Claim reason values#

Use is one of with comma-separated values when a rule should match multiple reasons or preferences (e.g. missing_product, wrong_product).

Example rule sets#

Always refund, no preference step#

Force a refund for trusted claim types — works even when your flow never asks the customer for a resolution preference.

1. Refund — claim reason equals damage AND claimed value ≤ 100
2. Manual — no conditions (catch-all)

Tiered value gates#

Route low-risk claims to automation; keep high-value orders manual.

1. Automate — claimed value ≤ 75 AND resolution preference equals refund AND claim reason is one of missing_product, wrong_product
2. Manual — no conditions (catch-all)

Reason-based routing#

Automate only the claim types your ops team trusts.

1. Automate — claim reason equals missing_product
2. Manual — claim reason equals dissatisfied_with_product
3. Manual — no conditions (everything else)

Replacement only when delivered#

Honor the customer's reorder request only after delivery is confirmed.

1. Automate — resolution preference equals reorder AND shipment status equals delivered AND claimed value ≤ 200
2. Manual — no conditions

Safety gates#

Your rules define what Karla may attempt. Karla still runs platform safety gates before executing a refund or replacement — even when a rule matches. If a gate fails, the claim falls back to manual handling and Karla records why.

Common automatic fallbacks:

Karla also treats an order as already processed once any claim on that order received an automated outcome — preventing duplicate refunds or replacements from repeat submissions.

These gates are not configurable in the portal today; they protect your shop regardless of how permissive your rules are.

Customer resolution preference#

What the customer selects in Resolve (when you expose the choice) drives the outcome of a matched Automate rule — Refund and Reorder rules ignore it:

The options customers can pick from are configurable under Resolve → Features → Resolution options in the portal — refund and reorder are enabled by default; enable keep with reward there to offer it. You control whether customers see the preference picker per flow in Flows and customization. Hiding the picker does not remove the preference from the claim: Resolve submits refund when the picker is hidden (or the sole configured option when only one is enabled), and a matched Automate rule acts on that default like any other preference. If you hide the picker, Automate simply resolves to that default for every widget claim — prefer the explicit Refund or Reorder action there so the intent is visible in your rule set.

API access#

Claim automation settings are available programmatically for headless or multi-shop setups:

curl -X GET "https://api.gokarla.io/v1/shops/{slug}/settings/triggers/claim-resolution" \
  -H "Authorization: Bearer YOUR_API_KEY"

curl -X PATCH "https://api.gokarla.io/v1/shops/{slug}/settings/triggers/claim-resolution" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "status": true,
    "notify_mode": "notify",
    "rules": [
      {
        "action": "automate",
        "conditions": [
          { "field": "claim_reason", "op": "equals", "value": "missing_product" },
          { "field": "claimed_value", "op": "<=", "value": 75 }
        ]
      }
    ]
  }'

A PATCH replaces the full rules array when you include it. Omit fields you want to leave unchanged. action accepts refund, reorder, automate, or manual.

Troubleshooting#

Automation never runs

• Confirm Enable claim automation is on.
• Confirm at least one Automate rule exists and its conditions match real claim data (check reason codes and claimed value).
• Confirm your shop connection supports refunds and replacements.

Rule matches but claim stays manual

• Check the claim's resolution outcome in the API — a safety gate may have blocked execution (out of stock, already processed, etc.).
• For Automate rules, confirm the claim carries a refund or reorder resolution preference — claims from other sources may have none, and keep_with_reward has no automated path. Switch the rule to an explicit Refund or Reorder action if the outcome should not depend on it.

Agents not notified after automation

• Set Notification mode to Notify if you expect helpdesk tickets for automated outcomes.
• Confirm your helpdesk integration is connected and enabled.

Wrong priority between rules

• Remember first match wins. Move stricter or higher-priority rules above broader catch-all rules.

Where to next#

• Integration and automation — helpdesk routing and custom transformations beyond claim automation.
• Shop connection — what Resolve needs from your shop.
• Data processing — the claim payload rules evaluate.
• Flows and customization — customer-facing resolution preference and flow toggles.
• Helpdesk integrations — tickets for manual claims and notify-mode outcomes.
• Portal → Resolve — claims analytics and the Claims table.