Working a case

A case is the record. Work it so that the next reader — an operator picking it up tomorrow, an admin checking why a response was late, the customer's own audit — can read it quickly and trust it. These rules were written against what went wrong when they weren't followed; see Lessons from past cases.

Before you do anything: read the whole case

get_case, then list_responses, then the timeline (query_events scoped to the case), then list_related_cases. Read to the end. A draft already exists, the customer already answered, a colleague already said what you are about to say — every one of those has happened to someone who read the top and started typing.

And read it again before you act on it. People and other sessions edit a case between your reads. Act on the latest read, never on a remembered one: the expected_version every write takes is the guard, and it only works if the version comes from a read you just made. Sending a remembered draft after a person had edited it is how the wrong text once went out.

Working the queue

When you are asked to work the queue rather than one case: find what is unassigned or yours (search_cases, list_my_cases), claim one, work it, finish or release it, take the next. Do not stop to ask which case to take, and do not stop because a case is hard — release it with a note saying what is missing and move on. Stop when nothing is left to claim, then report once: one line per case, its ref, and what now waits on whom. A message per case is noise.

Case or broadcast?

A case is one party's question or problem with a submitter waiting on an answer. A message OPN sends to an audience — an update, a maintenance window, a disruption and its all-clear — is a broadcast, even if you would once have opened one case per FI. The full test is in Case or broadcast?. Get this right before create_case.

Intake and the first response

• Create the case before researching. The record starts when the request arrives, not when you understand it. Owner entity, submitter, subject, type, priority; on behalf of only when a merchant or member other than the requester is the party concerned. The request is the message as received, headers and all — intake fills it; paste it when you open a case by hand or with create_case — and it is never edited. The description is your working summary of what is being asked.
• Component is optional; set it when the request makes it plain. A component is a definable part of the OPN stack (list_vocabularies → component: the Management Console, FedNow, RTP, the sandbox, the firewall…). It starts blank. Set it on create_case or update_case when the request names the part; never guess, and leave it blank rather than pick the nearest. An administrator maintains the list, and every term on it is visible to every entity — so a key you don't find isn't yours to invent, and never use a customer's name, an environment's id or any other instance as a term; say so in chat instead.
• The first response is a clock. Each priority has a first-response target; get_case shows first_response_due_at and overdue. A case whose real date moved (a release deferred a week) can be put on hold (hold_case with until and a reason): until then overdue is empty and held is true, and the case is not auto-escalated; the target does not move. Critical is measured on the wall clock (an outage doesn't wait): one hour of real time. The rest are business days, by close of business on OPN's calendar: high the same business day, normal the next business day, low the third. Day zero is the business day the case arrives on; a case that arrives after close, on a weekend or on a holiday belongs to the next business day. A normal case received Friday at 10:00, or Saturday, is due Monday at close; received Monday at 09:00 or at 17:55, Tuesday at close. Never quote a target to a customer as "24 hours": say the day. The rule and a table are in Response targets.
• A first response answers something. "We received your request" is sent automatically; your first response says what you found, what you need, or what the next step is and who holds it. Acknowledging again is not a first response.
• Claim before working (claim_case), release if you stop (release_case). An unclaimed case in the Unassigned list is someone else's to take; two people working one thread produces two answers.
• Noise is dismissed, not answered. Intake opens a case for whatever arrives. A calendar reply, a delivery report, a digest, a mail-provider report is not a request: dismiss_case with a note saying what it was — the type becomes noise, the case resolves, it leaves the figures, and no notice goes out. The test, who decides, and what is not noise are in the playbook: an agent dismisses only mail from an automated sender with no question in it, and reports anything from a person for a person to decide.
• A proactive case has no submitter message. A problem OPN's own monitoring found — transfers waiting too long, a failed probe — is a case OPN opens itself. Its evidence is a table in a note, one row per transfer, not prose; nothing goes to the customer unless they must act, and the first response, if there is one, is that message.

Notes: facts and evaluations

Notes are the case's own section above its timeline, newest first, dated and attributed; a person reading the case reads them before the timeline. Put what you established in a note (add_note) so it survives the session:

• transfer ids, workflow names, statuses and timestamps, verbatim from the source;
• what a document or log says, and what it does not;
• the one thing you had to decide when the source was ambiguous, and why.

An evaluation is a note. Where the case stands, what the evidence supports, what would settle it: write it as a note that starts with what it is ("Evaluation: …"). A later evaluation supersedes an earlier one; nothing is edited or deleted, so the reasoning at each point stays readable. Keep it short — a paragraph, not a report.

Leave out predictions ("it likely did not"), recommendations to OPN, narrative connecting the dots, source-code proofs, exhaustive schema inventories, cross-case comparisons, and commentary about your own drafting. Those belong in chat, where a person can act on them.

✅ "Transfer 13706464756: send_rtp_credit, step network_submit completed 16:03:12 UTC, network status ACSC. No debit step recorded." ❌ "It looks like the transfer probably went through but I'd want to double-check with engineering before we say so."

Status, and what each one means

Resolved reopens on its own when the customer replies. Closed does not: reopen_case is an admin's correction for a case closed by mistake, and create_followup_case is the path for a customer who comes back. Never use closed to make a backlog look smaller.

No-reply closure. A case may be resolved once seven or more calendar days have passed since OPN's last outbound message with no reply — and only if the ball was genuinely in the customer's court. "Awaiting their reply" while an OPN to-do sits undone is not that.

One next action

The case carries one next action and who holds it, in its next action field (update_case with next_action; shown under the description, in the head as Next: …, and as a list column). One line or two of Markdown, up to 500 characters: the action and whose move it is — "Rosa sends the HAR file; then we reproduce on the sandbox." Not a numbered backlog. If you can name three things to do, do the first and record the second; the third is usually not this case's. Clear it (an empty string) when nothing is pending. A case pending internal still names what it is blocked on in blocked_on; the next action says what happens when that clears.

What to change, when

• As the case moves: set the next action and add a note. That is the ordinary rhythm — every message in or out, every fact established, moves one or both.
• The description only when the request itself has materially changed: the customer restated the problem, the scope grew, the first reading was wrong. Restating your progress there is what turned legacy cases into thousand-line files.
• The request, never. It is the record of what was asked.

Related cases

link_related_case with duplicate_of, related_to or follow_up_of. A duplicate is closed with the link; a follow-up is created from the closed case with create_followup_case so the on-behalf-of, submitter and type carry over. Do not merge threads by copying text between cases.

Escalation is internal

escalate_case raises priority, can reassign, and pings the team; it never contacts the customer. Reserve it for what needs another person's attention now: funds at risk, a target about to be missed, a decision above your level. de_escalate_case when it's handled.

Time

start_time_entry when you begin, stop_time_entry when you stop, or add_time_entry after the fact with a note saying what the time was for. Totals feed the case and the weekly figures; a note like "read the step log, drafted the reply" is enough.

Messages sent outside the tool

Every message to a customer leaves from the tool, threaded on the case's reply address, so the reply comes back to the case. A reply from someone's own mailbox is the exception — a thread the customer already has with that person — and it leaves no record here. If one happens, add the sent text to the case as a note the same day, marked as sent outside the tool; the first-response clock is the tool's, and a message it never saw does not stop it.

What never goes in the record

• Full account numbers. Redact to the last four: XXXX3456. Routing numbers are public.
• Account balances. Record the outcome of a step (OK, POSTED, ERROR) and its time, never the figure.
• Other customers' names. A pattern seen elsewhere is described as "another institution" or not at all.
• Credentials, tokens, one-time codes, screenshots of account data.
• Secrets a message must carry go in as a placeholder — "(secure share link, supplied by the sender)" — and the person who sends supplies the value. Never write a real one into a draft or a note, and never invent one so the draft looks complete.

The archive redacts a closed case's free text after the retention cutoff; it does not unwrite what was sent.

Concision

A case that cannot be read and understood quickly has failed. The legacy tool's target for a whole case file was eighty lines; one drifted past a thousand because it stopped answering the customer and became a research archive. The customer's request in full, every message in both directions in full, the facts you established, one next action. Everything else is chat.