Pricing rules
Automatic price movement that can never breach the floor.
TL;DRAI summary
Pricing rules automate how your vehicles are priced and listed based on their attributes. This helps you quickly price many vehicles, ensuring they are always listed at or above your set floor price, and lets you automatically adjust prices over time.
For: Cypress Managers · org admins (org-level rules live in Settings)
Pricing rules answer the question every remarketer asks at scale: who prices four hundred vehicles? A rule matches vehicles by their attributes and computes their numbers — listing price and offer bands — every one anchored on the seller's floor, which is what makes automated pricing safe to run.
How a rule decides
A rule is conditions plus outcomes. Conditions match on what the vehicle is — make, type, mileage, year, condition score, location, labels, or how its floor compares to the valuation. Outcomes are one of three: approve & list (price it and launch it), require manual review (price it and wait for a human), or auto-reject (this vehicle isn't listing yet).
Rules evaluate in strict order — org rules before global rules, then by priority, and the first match wins. Everything after the first match is skipped and the evaluation log says so. And if nothing matches, the fallback is always manual review — no rule ever means "list it silently."
The three percentages — all anchored on the floor
A matching rule computes three numbers from one input, the FM's floor:
listing price = floor × (1 + target markup %)
auto-accept at = listing − (accept-below-target % of listing)
auto-deny below = floor × (1 + deny-above-floor %)The geometry guarantees the promise: every computed number sits at or above the floor, so a pricing rule can move the ask and the bands all day without ever selling below the seller's line.
Where rules run
- At submission — a vehicle entering pre-listing meets the rules; an approve & list match with auto behavior launches it, bands armed, no human in the loop. A notify behavior stages the same result for a CM's one-click approve.
- On demand — apply a rule to one vehicle or a bulk selection from Fleet; preview first, confirm second.
- From an automation — the
APPLY_PRICING_RULEaction in automations — how time-based markdowns actually run. - Dry run — test an unsaved rule against real inventory before it exists.
Org-level rules live in the org's Settings → Pricing Rules; platform rules under Admin. Same engine, same ordering promise.
Worked example
Acme's markdown ladder, applied by the stale-listing automation: −3% at day 14, −4% at day 28, −5% at day 42, each recomputing from the current ask, clamped at the floor. The Transit starts at $32,500 → $31,525 (day 14) → $30,264 (day 28) → the day-42 step computes $28,750, below Maria's $29,000 floor — so it clamps to $29,000 and stops. The staircase ends on the floor, never through it. (In our story Dan's offer landed on day 9 — the ladder never got past its first step.)
Business rules
- Every evaluation is logged condition by condition — which rules were skipped, which matched, what was computed, and what the floor and valuation were at that moment.
- A price a rule changes re-arms the offer bands and notifies the same surfaces a human change would — rules have no quiet mode.
- Rules never touch the floor itself. The floor is input, never output.
Under the hood
Rule evaluation snapshots its inputs (floor, valuation) per run; applied rules stamp the vehicle's auction rule with an immutable audit of what configured it. Integrator-pushed prices coexist: a CM pricing-rule configuration outranks a price push's derived bands — the precedence is documented in the developer pricing docs.