Case types — what to gather, check and say

Generic playbooks for the recurring shapes. Product runbooks with institution-specific detail live with OPN's operators, not here; these are the questions that are always the same. The types below are the ones every deployment starts with; an administrator may add more (list_vocabularies → case_type is the live list), and a type without a playbook here is worked like question until one is written.

access — resets, console access, permissions

Gather: who (the user as the system knows them), what they cannot do, the exact error and where it appeared, since when. Check: does the account exist and is it active; is MFA enrolled or expired; did a temporary credential expire; did a recent change (a profile move, a group change) invalidate credentials issued before it. Say: what was done, when the temporary credential expires, that MFA must be re-enrolled, and the one thing to try if it still fails. Confirm from the system that it worked before resolving.

configuration — linking, limits, enabling a capability

Gather: the exact object (the customer's name for it and the system's id), the current value, the requested value, and who authorised it — some changes need a written approval from the sponsoring FI before they are made. Check: the current state from the system, not from the request; whether the requested value already applies by default; whether the change affects other parties. Say: what was changed, as a data block anchored to the old value, and the self-service path for next time if one exists. Never volunteer OPN to make changes the customer's own tooling makes.

transfer — stuck, waiting, returned, duplicated

Gather: both transfer ids where a return or a request creates a second one; the amount; the timestamps; what the customer's system showed. Check: the step log for whether funds moved (a debit step, a network submission, a settlement), the network status codes, and which counterparty holds the next step; a debit or credit step retried with a duplicate flag set is duplicate-funding exposure and is said as such; and for a payment that never reached the receiving institution, whether that institution is enrolled in the network (in the routing directory) as against signed on (connected right now) — a bank can be enrolled and not signed on, which is its own status, and the integrator can query both itself through the routing-number query endpoint (view_history permission) before sending. Say: plainly whether funds moved, what the next step is and who holds it (the network, the receiving institution, the customer), and what the two outcomes look like. Never write full account numbers or balances. A recurring failure at one institution is a note on the case, not a claim to another customer.

security — allowlists, WAF, certificates, suspected fraud

Gather: the source addresses or ranges, the change ticket on the customer's side, the exact rejection and where it was seen. Check: which party's control produced the rejection — the customer's firewall, a vendor's, or OPN's — before anyone opens a ticket; whether a change on one side recurred. Say: what OPN sees, what the customer's next step is (usually their change ticket), and what OPN will confirm once it lands. If people may need to act fast, an outage alert is a broadcast about the case.

question — how-to, clarification, guidance

Gather: what they are trying to do, not only what they asked. Check: whether a document, a published guide or a console page already answers it. Say: the answer, the self-service path, and the one obvious wrong turn to avoid. Resolve on the reply; it reopens if they come back.

onboarding — a new integrator, FI or merchant coming onto the platform

Gather: who is coming on (the organisation, the sponsoring FI, the integrator if any), which stage they are at (sandbox request, credentials, testing, network participation, go-live), what they have already been given, and who on their side and OPN's owns the next step. Check: the checklist for that stage from the system, not from the request; whether the sponsor's approval is on file where one is required; whether a sandbox or credential already exists before making another. Say: the stage, what was done, what is needed from them next and by whom, and the date the next stage can happen. An onboarding runs for weeks: keep one case, and note each stage on it rather than opening a new case per email.

incident — an outage or degradation affecting more than one transfer

Gather: what is failing (the platform, a network, a core connection, a vendor), since when, who is affected, and what still works. Check: whether the symptom is one institution's or everyone's; which party holds the fix; whether transfers are queued or failed. Say: the scope, what still moves, who holds the next step, and when the next update comes — then the all-clear. Report impact as a window and counts (completed, cancelled, retried) in a data block, not as a narrative. If people may need to act, an outage alert is a broadcast about the case; the individual stuck transfers that come in during it are their own transfer cases, related to this one. Keep the incident open until the all-clear is sent and the affected transfers are accounted for.

notice — a production update, maintenance window, disruption or vendor notice

Two directions. OPN's own notices to customers are broadcasts from now on; a notice case from before the cutover is that history. A notice OPN receives — a core's maintenance window, a cloud provider's health notice, a domain migration — is a case so the follow-through is tracked. Gather: the window, what is affected, who sent it. Check: whether anyone at OPN or a customer must act before the window, and whether customers need telling (a broadcast). Say: what OPN will do and when, and the all-clear afterwards. Resolve on the all-clear.

defect — the product misbehaves

Gather: the exact steps, what happened and what was expected, the ids involved, since when, and whether it is reproducible. Check: whether it is a known issue with a workaround; whether a recent release explains it; whether the customer's own change explains it. Say: what is known, the workaround if there is one, and that engineering has it — then the fix and its date. Set the case pending_internal with the engineering ticket as Blocked on while it waits, and never promise a fix date engineering has not given.

business — a commercial matter that reached support

A demo request, a partnership or pricing discussion, an offboarding, a legal document or review, a vendor's payment change, a shareholder's request, meeting coordination with a partner or a network: not a support problem, but the person wrote to support and someone must answer. Gather: who they are, what they want, and by when. Check: who at OPN owns that relationship, and whether there is already a thread with them. Say: that it has reached the right person, who that is, and what happens next — nothing more; support does not negotiate, price or sign. Resolve on the hand-off, and note where it went.

noise — what intake opened that was never a request

The test: noise is mail that no person is waiting on an answer to. A calendar reply, a delivery report, a digest, a mail-provider report, a bot, an accidental send with nothing asked, spam that scored under the threshold. Anything a person wrote expecting something back is a case, however odd it looks, and a misdirected question still gets a short answer, not a dismissal. Automated wrappers hide requests: a boarding request once arrived as a notification and was filed as a note, and nothing happened until the merchant's first payment failed (the lesson). Read the whole message before deciding.

Who decides: dismissing resolves the case and sends nothing, so a wrong call means someone who wrote to support hears nothing. An agent dismisses only the mechanical kinds — a no-reply or automated sender with no question in the body — and reports anything from a person in chat for a person to decide.

How: Dismiss as noise on the case (dismiss_case over MCP) with a note saying what it was: the type becomes noise, the case resolves, it is left out of every figure, and no closing notice goes out. Say nothing to the sender. If the same noise keeps arriving, say so in chat so the intake rule can learn the pattern — never on a single sighting. Wrong call? Edit the type back and reopen.

Not intake: an out-of-office or other auto-reply to a message of ours lands on the existing case as an inbound message. There is nothing to dismiss; leave it, and do not treat it as the customer's reply — the ball is still where it was.

other — and what should not be a case

OPN's own internal tasks — engineering work, infrastructure tests, marketing — are not support cases: they have no outside requester, and they belong with the team that does them, not in the queue. A production update, a maintenance window, a disruption or its all-clear is a broadcast. What is left in other is what fits no playbook above; if a shape keeps appearing here, it wants a type.