How to Set Resolution Rules That Close Cases Without a Human Touching Half of Them

A resolution portal doesn't save you time because it's self-service. It saves you time because of what happens behind the form: the rules that decide which cases resolve themselves and which ones need a person. Get those rules wrong and you've just built a prettier support queue.

The Portal Isn't the Product. The Rules Engine Is.

Most merchants evaluate a resolution portal by its front end. Can the customer file a resolution without emailing support? Does it look clean on mobile? Those things matter, but they're not where the time savings come from.

The savings come from automation logic that can tell the difference between a customer whose package genuinely never arrived and a customer running the same play for the third time this quarter. If your rules can't make that distinction, you end up either auto-approving fraud or routing everything to a human anyway, which defeats the purpose of the portal entirely.

Designing that logic well means thinking in layers, not one big yes/no gate. Here's how to build it.

Start With the Variables That Actually Predict Risk

Before you touch a single toggle, decide what signals your rules engine should even look at. Most merchants over-index on order value and ignore the signals that matter more.

The variables worth building rules around are:

• Order value. Sets the ceiling for what auto-approves versus what needs review.
• Carrier status. Whether the carrier confirms the package as lost, confirms delivery, or shows no scan activity at all.
• Resolution history. How many resolutions this customer, shipping address, or IP has filed in a given window.
• Resolution reason. Lost in transit, damaged, stolen after delivery, or never arrived all carry different risk profiles and need different rules.
• Time since delivery. A resolution filed two days after a "delivered" scan behaves differently than one filed six weeks later.

Every rule you build downstream is a combination of these five variables. If you skip this step and just start setting thresholds, you'll end up with rules that don't hold up under real order volume.

Build Auto-Approval Logic in Tiers, Not One Big Rule

The mistake most merchants make is trying to write a single rule that decides everything, like "auto-approve if under $75." That threshold alone ignores resolution history, carrier status, and reason code, so it either auto-approves obvious fraud under $75 or forces you to lower the threshold so far that the portal stops saving anyone time.

Instead, structure the rules engine in tiers, where a case has to clear multiple checks before it auto-closes:

• Tier 1: Order value cap. This is the outer boundary, not the whole decision. A common starting point is auto-approving resolutions under a dollar amount that reflects your average order value, not an arbitrary round number.
• Tier 2: Carrier confirmation. Within that value cap, split cases by what the carrier's tracking data actually says.
• Tier 3: Customer history. Within carrier-confirmed cases, check whether this customer or address has an unusual resolution pattern.

Only cases that clear all three tiers auto-close. Everything else routes to a queue, but it's a much smaller queue than "everything," because most legitimate resolutions clear all three tiers without issue.

Order Value Caps: Set the Ceiling, Not the Whole Rule

Order value caps exist to limit exposure, not to judge legitimacy. A $40 resolution and a $400 resolution carry the same fraud risk if the underlying signals are identical, but the dollar amount changes how much scrutiny you can afford to skip.

A workable approach: set a low-value auto-approval tier, say under your median order value, with looser secondary checks, and a higher-value tier that still allows auto-approval but only when carrier data and customer history are both clean. Anything above that ceiling routes to review regardless of how clean the other signals look, because the downside of a wrong auto-approval scales with order value.

Resist the urge to set one number and stop there. A single flat cap either leaves money on the table if it's too low, or leaves you exposed if it's too high. Tiered caps solve both problems at once.

Repeat-Resolution Flags: Catch the Pattern, Not the Customer

Repeat resolutions are your highest-signal fraud indicator, but they're also where merchants most often over-correct and burn goodwill with legitimate repeat customers.

The fix is to flag on patterns, not raw counts. A customer who orders frequently and files one resolution over a year is not the same as a customer who files three resolutions in six weeks, or an address that's filed resolutions across five different customer accounts. Build the rule around velocity and cross-account patterns, not a single "more than one resolution" trigger.

Practical thresholds to configure:

• Resolution count per customer within a rolling window, such as more than one resolution in 60 days, triggers manual review, not automatic denial.
• Resolution count per shipping address, independent of the account filing it, catches fraud that spreads across multiple accounts.
• Repeat resolution with the same reason code, such as three "stolen after delivery" resolutions from the same address, is a stronger signal than three resolutions with varied reasons.

None of these should auto-deny. They should downgrade a case out of the auto-approval tier and into human review, because a flag is a reason to look closer, not a verdict.

Carrier-Confirmed-Lost vs. Disputed: The Highest-Leverage Rule You Can Build

If you only build one smart rule, build this one. The single biggest driver of how much a resolution portal can automate is whether the case has a clear, third-party-confirmed answer or whether it's a dispute between the customer's account and what the tracking data shows.

Carrier-confirmed-lost cases, where the tracking data shows no movement for an extended period or the carrier's own systems mark the package lost, are the closest thing to a verified fact you'll get. These should sit in your fastest auto-approval path, because you're not taking the customer's word for it. You're taking the carrier's.

Disputed cases, where tracking shows "delivered" but the customer says it never arrived, are a different animal entirely. There's no third party confirming the customer's version of events, so these need a different rule set, typically a review step or a secondary verification such as a photo, delivery address confirmation, or a short waiting period in case the package is delayed rather than actually lost.

Building this distinction into your rules engine is what separates a portal that resolves 60% of cases automatically from one that resolves 15%, because most resolution volume splits fairly evenly between confirmed-lost and disputed-delivery cases. Automating the first category well is where the real time savings live.

Escalation Triggers: Decide in Advance What Always Goes to a Human

Auto-approval rules define what closes itself. Escalation triggers define the opposite: the conditions that should always pull a case out of automation, no matter how clean the other signals look.

Build these explicitly rather than leaving escalation as a default fallback:

• Order value above your top-tier cap, regardless of other signals.
• Any resolution flagged by both the repeat-resolution rule and a carrier dispute.
• New customer accounts, under a set order count or account age, filing a resolution on their first or second order.
• Resolution reasons your team hasn't built a rule for yet. Anything unclassified should route to a human by default, not auto-approve by default.

The point of explicit escalation triggers is that your rules engine should never be guessing. Every case either matches a defined auto-approval path or it lands in review. There's no ambiguous middle ground where a case slips through because no rule was written for it.

Test the Rules Against Real Cases Before You Trust Them

Once the tiers are built, run them against your last 90 days of resolution history before turning on auto-approval for real customers. Check what would have auto-closed, what would have escalated, and whether either bucket contains a case that surprises your team.

This step catches the gap between how the rules look on paper and how they behave against actual order patterns. A threshold that looks reasonable in the abstract sometimes auto-approves a cluster of cases you'd have caught by hand, or escalates so much volume that automation isn't doing its job.

Revisit the thresholds quarterly. Order value, product mix, and fraud patterns shift, and rules that were well-calibrated in January can drift out of tune by the time your order volume doubles.

Set It Up Once, Let It Run

The merchants getting the most out of self-service resolution don't have a bigger support team. They have a better-configured rules engine, one that auto-closes the clean, carrier-confirmed cases instantly and routes the genuinely ambiguous ones to a person.

ShipAid's Self-Service Resolution Portal gives you the tiered rules engine to configure order value caps, carrier-confirmed-lost logic, repeat-resolution flags, and escalation triggers, all from your dashboard. Set up your resolution rules and let automation handle the cases that don't need a human, so your team's time goes to the ones that do.

Frequently Asked Questions

What's the difference between a resolution portal and a rules engine?

A resolution portal is the front end customers use to file a resolution instead of emailing support. The rules engine behind it is what decides which cases close automatically and which ones need a person, and that decision logic is where the actual time savings come from.

What variables should a resolution rules engine evaluate?

Order value, carrier status, resolution history, resolution reason, and time since delivery. Every downstream rule is a combination of these five variables, so skipping this step leads to thresholds that don't hold up under real order volume.

Should order value caps be a single flat number?

No. A single flat cap either leaves money on the table if it's too low or leaves you exposed if it's too high. A tiered approach, with a looser low-value tier and a stricter high-value tier that still checks carrier data and customer history, solves both problems at once.

Should repeat resolutions be automatically denied?

No. Repeat resolutions should downgrade a case out of the auto-approval tier and into human review, not trigger an automatic denial. The rule should target patterns like velocity and cross-account activity, not a single customer filing more than one resolution.

How often should resolution rules be reviewed?

Revisit the thresholds quarterly. Order value, product mix, and fraud patterns shift over time, so rules that were well-calibrated in January can drift out of tune as order volume changes.