Help

Lessons from past cases All help

Lessons from past cases

Patterns from the support work that preceded this tool, anonymised. Each is a rule, what happened, and why it mattered. The rules elsewhere in these guides mostly come from here.

What worked

  • Ask for evidence as a numbered list. An FI reported a 403 with a screenshot. The reply asked for three things by number: the transfers involved (date, amount, any id), the page or URL, and the text behind the error dialog's Details button. The detail came back the same evening. Open-ended "can you tell us more" gets prose; numbers get answers.
  • Verify a click-path before asserting it. A draft told an admin to open a tab that did not exist and a menu item with a different name. Checking the console before sending corrected both. If you describe a screen, look at it first, or say you are describing it from memory.
  • The system is the ground truth, not the request or the config file. A request, a spreadsheet and a screenshot spelled a merchant's name three ways; the console had the right one. Manager links were confirmed from the member export, not from the change that was meant to create them. When you report a state, read it from where it lives.
  • Confirm recovery independently before announcing it. A connectivity probe said a core was back; a manual check confirmed it before the all-clear went out. An all-clear that is wrong costs more than an all-clear that is an hour late.
  • Give the self-service path instead of taking the task. A test-account funding request was done — and the reply also showed the endpoint the integrator's own code already used, so the next one never became a ticket.
  • Routine access work has a shape; use it. Password resets and console access closed same-day when the reply carried the same three facts every time: what was reset, when the temporary credential expires, and that MFA must be re-enrolled. Reuse the shape; don't re-derive it.
  • A call closes a stuck thread. More than one case with eight emails on the thread resolved in a single call; the draft written for it was never needed. When a thread is going back and forth on the same point, propose a call and note the outcome on the case.
  • Correct a wrong root cause before it ships. A "backend provisioning gap" was actually a field-selection error; a "core defect" was testing against an unconfigured environment. Both were caught in review. State the mechanism, and check it against a precedent (a working example) before it goes out.

What didn't

  • A draft written and never sent, while the customer chased. One request was answered in a draft on day three and sent on day twenty-six after three chases; the first response field stayed blank the whole time. Another integrator chased four times against a draft that was never sent. A draft is not a response. If a draft is waiting, the next thing to do is get it reviewed, not to write more; and a draft not sent the day it was written should be re-read against whatever the customer said since.
  • Two people answering one thread. A colleague told a customer he would "check with the support team" while the team's reply was already out. Claim the case; check the correspondence before replying; if someone else is on it, coordinate in chat, not on the thread.
  • The confirmation went to a no-reply address. A change was made and confirmed to the automated address that had sent the request, with the real person only on copy. He asked twice more. Reply to the person, at the address a person reads.
  • A request logged as a note on the wrong case and missed. A boarding request arrived as an automated notification and was recorded as a note under a different merchant's case; nothing was opened and nothing was done until the merchant's first live payment failed. A request is a case the moment it arrives, with its own ref and its own clock.
  • The most useful question was drafted twice and never asked. During an outage the same misfire recurred as three days earlier; the question that would have found it ("did an endpoint or network change recur on your side?") was drafted into two messages and cut from both. Meanwhile the FI opened a ticket against the wrong vendor for the second time. If a question would change what the customer does next, it goes in the first message.
  • Thirteen days to a first response on a live integrator question. The reply eventually opened with an apology. First responses are a clock; an early answer that says what you know and what you need beats a complete answer that is a fortnight late.
  • Notifying before validating the fix. A webhook fix was announced before the test that would have proved it was run. Run the test, note the result, then tell the customer.
  • Closing on silence with an unverified premise. A case was resolved after eight quiet days on the theory that a configuration gap was the blocker, when the customer had got past the error on a call and the gap was never confirmed as real. Silence closes a case only when the ball was genuinely theirs.
  • Anticipating a follow-up and not answering it. A case noted that the customer would want the sandbox and production entries separated in an IP list, sent the combined list anyway, and was reopened for exactly that. If you can see the next question, answer it now.
  • The cached draft. A draft body kept from an earlier read was sent after the person had edited it on the case; the customer got the unedited text. Read the draft again immediately before sending, every time; the version check exists for exactly this.
  • The thousand-line case. Two cases grew past a thousand lines of superseded drafts, struck-through backlogs and research; the purpose had drifted from answering the customer to accumulating an archive. Keep the request, the messages, the facts and one next action; put the rest in chat.
  • Proactive notices opened as one case per FI. A sixth of the archive was production updates, sandbox releases and maintenance notices, each opened as a case per recipient. They buried the real queue, made "resolved" mean "sent", and skewed every metric. See Case or broadcast?.

What the figures showed

Over one summer the weekly average first response drifted from a few hours to over two days, and average resolution roughly doubled. On the last snapshot before this tool, seven of the ten open cases were waiting on a person inside OPN to review and send a draft — not on the customer. The bottleneck was the send gate, and the unsent-draft failures above are its symptom. This tool keeps the gate (a person always sends) and makes the queue visible: the Needs review scope, the rail count, batch approval, and a first-response clock on every case.