Claim automation#

What you need#

Before turning automation on:

• Resolve enabled on your Karla package.
• A connected Shopify shop — automated refunds and replacements are executed in Shopify, so automation only completes for Shopify shops. Rules on other platforms fall back to manual handling. 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.

Claimed value and Claimed quantity are numeric — they take a number (the portal labels the box "Amount" and "Item count" respectively) and do not support is one of.

Claim reason values#

Shipment status values#

Shipment status matches the shipment's current phase, entered as a plain value: order_created, order_processed, order_cancelled, in_transit, in_delivery, collect, delivered, delivery_failed, returned, or return_failed.

Use is one of when a rule should match multiple reasons, preferences, or statuses (e.g. missing_product and wrong_product).

Return shipment status values#

Return shipment status matches the phase of the return parcel — the one travelling from your customer back to you — and takes the same values as Shipment status above. The two are independent: Shipment status always describes the original outbound delivery.

delivered on the return parcel means the goods have arrived with you. That is the value to use for "refund once I have the goods back".

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 below or equal 100

Anything else falls through to your team.

Tiered value gates#

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

1. Automate — claimed value below or equal 75 AND resolution preference equals refund AND claim reason is one of missing_product, wrong_product

Claims above €75 match no rule and stay manual.

Reason-based routing#

Automate only the claim types your ops team trusts, and stop a specific reason from reaching a broader rule below it.

1. Manual — claim reason equals dissatisfied_with_product
2. Automate — claim reason is one of missing_product, wrong_product

Because the first match wins, listing the Manual rule first keeps dissatisfaction claims with your team even if you later widen rule 2.

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 below or equal 200

Refund a return once the goods are back#

The safest setup for a returns-heavy shop: the customer gets an automatic refund, but only after the parcel physically reaches your warehouse.

1. Refund — claim reason equals return AND resolution preference equals refund AND return shipment status equals delivered

Nothing is refunded at submission, because there is no return parcel yet. Karla re-checks the claim as the return travels and refunds when it arrives. If the customer never sends it back, the claim stays open for your team.

Small quantities only#

Automate single-item claims and keep bulk claims under human review.

1. Automate — claimed quantity below or equal 2 AND claim reason equals missing_product

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:

A claim whose claimed value cannot be calculated is not stamped with an outcome at all — a value condition simply does not match, so the rule is skipped and the claim falls through to manual handling like any other non-match.

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, and every rule must carry at least one condition.

Operators over the API are equals, in, <=, <, >, and >=. The in operator takes a JSON list, not a comma-separated string:

{
  "field": "claim_reason",
  "op": "in",
  "value": ["missing_product", "wrong_product"]
}

Numeric fields (claimed_value, claimed_quantity) take a number and reject in; categorical fields (claim_reason, resolution_preference, shipment_status, return_shipment_status) reject the numeric comparison operators.

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 the shop is connected to Shopify — refunds and replacements are executed there, and shops without Shopify access fall back to manual.
• Confirm no rule targets the deprecated partial_damage reason; use damage.
• If the rule should fire once a return arrives, confirm it conditions on return_shipment_status (not shipment_status, which is the outbound parcel). Without that condition a rule is evaluated once, at submission, and never waits for a later status.

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.