Retailers, hotels and restaurants make the same small calls millions of times: take this return, honor this discount, move this guest. Each one is minor, but together they decide margin and loyalty. Helixor makes them consistent across channels and tunes them from what actually happens next.
These are examples, not a complete list. A decision usually fits when it has written criteria, pulls from several systems, happens often, and someone may later ask why it went the way it did. Pick one to jump to it.
A return at the counter or online depends on the receipt, the item's condition and category, how long it's been, the customer's return history, and the payment method. Associates improvise, policies differ by channel, and return abuse hides in the gaps.
Helixor applies one returns policy everywhere: approve, approve as store credit, refer to a supervisor, or decline. Associates see the reason on screen, which makes the conversation with the customer easier. Chargebacks, resale value and supervisor overrides come back as outcomes for the next version.
{
"transaction_id": "POS-8841-20260928-0193",
"receipt": "hx_proof_19b4d7e0a2c3f58e6d71b0a4",
"pack": "acme.returns_policy v9",
"action": "store_credit_only",
"rules": ["RET-NO-RECEIPT-HIGH-VALUE"],
"input_sha256": "2ac9...f07b",
"remedy": ["provide order_number or receipt"],
"logged_at": "2026-09-28T19:02:44Z"
}Hotels overbook because some guests don't show. How far to go depends on forecast no-shows, events in town, room types and the cost of walking a guest. When the hotel is oversold, the front desk decides who gets moved, often late at night and without much guidance.
Helixor applies your overbooking limits by date and room type, and when a walk is needed, picks who moves using your written priorities: loyalty tier, length of stay, rate, and whether the guest has already been moved before. The guest gets a consistent offer, and the property can see later why each person was chosen.
Associates and sales reps ask for discounts all day. Approval limits depend on role, margin, item and customer, and the rules usually live in a manager's head.
Each request comes back approved, refer to a manager, or declined, with the margin impact and the reason. Managers only see the requests that need them.
An online order can ship from a warehouse, a store's back room or a mix of both. The right answer depends on stock, distance, carrier cutoffs, store labor and whether shipping from a store will empty its shelf. Many retailers use a fixed priority list, which is simple and often expensive.
Promise dates, safety stock rules and store capacity go into the pack, and the goal is the lowest total cost to fulfill. The solver assigns orders in batches through the day and rebalances when stock or labor changes. Every assignment is checked by the decision core, so no order goes to a site that can't legally or physically ship it. The pack holds the hard rules and the goal. The solver searches for the best plan that satisfies every hard rule, working from the same typed state the decision core uses. If no plan can satisfy them all, it tells you so instead of quietly breaking one. The solvers are built for GPUs, and that's where large plans solve fastest. Solvers are in Preview today.
| Decision | What Helixor decides |
|---|---|
| Order and booking consistency | Check dates, options and quantities against policy before the order is confirmed. |
| Workload | Pattern |
|---|---|
| Point of sale, checkout and booking | In-process or loopback sidecar |
| Many channels | Shared, authenticated decision service |
| Allocation, capacity and exceptions | Hosted solvers and reasoning (hybrid) |
Returns and discount policies need a custom pack, and demand forecasting needs an outside model. Solvers and reasoning are currently in Preview. Start with one decision, such as returns in one channel, and compare override rates before and after.
Go deeper on helixor.dev: Industry guide ↗ • Deployment patterns ↗ • Core concepts ↗ • Receipts ↗
Bring a written policy and a handful of past cases. We'll turn it into a pack and run it next to your current process so you can compare.