Cutoff

• 

• 

• 

• 

• 

The short version

Cutoff puts every dispute on a timeline against its real PayPal response deadline, one row per handler, so a team can see the shape of the day rather than read a list.

When a case arrives or moves, an agent reflows the remaining work around the deadlines already there, and explains in plain words what it moved and why.

One dispute on the board is genuine, with its real deadline. The rest are seeded, because PayPal's sandbox offers no way to create one.

---

A queue is the wrong shape for a deadline

PayPal gives a seller a fixed window to answer each dispute. Miss it and the case is decided for the buyer — not on the evidence, on the silence.

So a dispute team is not really managing a queue. It is managing a set of deadlines, several at once, against people who each have a finite number of hours. Those are different problems. A list sorted by date tells you what is next. It does not tell you whether the next four fit in the time left, or who is already overloaded, or what happens to everything else if a big case lands this afternoon.

Cutoff puts every case on a timeline against its real PayPal response deadline, one row per handler. You can see the shape of the day instead of reading it.

---

When something moves, the agent reschedules

Click Send in a new dispute and one arrives. The agent finds room for it — against the deadlines already on the board, the value of each case, and how loaded each handler is — and then explains in plain words why it put it where it did.

Drag a case to someone else and the same thing happens in reverse: the remaining work reflows around the gap.

The explanation matters as much as the placement. A scheduler that silently rearranges your day is a scheduler people stop trusting. This one says what it moved and why, every time.

The Queue tab is the same information as rows, for anyone who would rather read than look. The Calendar tab is the same again by day.

---

One of these disputes is real

PP-R-IQQ-10190238 is a genuine PayPal dispute, filed by a sandbox buyer through PayPal's own Resolution Centre against a payment we captured. It sits on the board with its real deadline, scheduled alongside the rest.

Getting it onto the board taught us something that is not in the documentation. A newly created dispute does not appear in GET /v1/customer/disputes straight away. For the first few minutes the list returns an empty array and every dispute_state filter returns nothing, while a direct fetch by id returns the whole object. The board therefore fetches known ids directly and merges them with whatever the list returns.

The rest of the queue is seeded, for a reason worth stating plainly: PayPal's sandbox has no API that creates a dispute. Only a buyer can open one, in a browser. We did that by hand to get the real case above. Doing it a dozen more times would need a dozen sandbox buyers and a dozen browser sessions.

---

Built With

• bedrock
• claude
• lambda
• paypal
• sonnet