Consensys account-escalation audit

Last updated: 2026-08-23

Reference: Rho / Consensys, Rulebase conversations 4250201, 4250314, 4251299, 4251432, 4251540, and 4251556.

Six related customer contacts produced no successful Slack escalation. This audit records why, what changed in production, and what remains before Consensys becomes a passing regression case.

Incident

The customer contacted Rho six times in 3 hours and 22 minutes:

The first three calls were marked solved within approximately 7-16 minutes; the account incident remained unresolved until August 20-21. The main email eventually involved nine agents, but only three frontline agents received ticket-level quality evaluations.

The calls scored 90%, 100%, and 70%. Three evaluations on the email each scored 100%. They correctly rewarded safe communication, privacy, and escalation, but did not ask whether the account was progressing toward resolution.

Every touch can be handled correctly while the account is still being failed.

Contact surge and missed promise

The early and late warning signals were different:

Contact velocity should create the incident. Unresolved follow-up and missed promise should show that it is worsening.

Failure and remediation ledger

Supporting evidence

Complaint classification

No target conversation emitted complaint.created or complaint.notified, although both events worked for other Rho conversations in the same period. Treating every fraud dispute as a complaint would create false positives. The account-level combination of repeated contact, fragmented handling, a serious topic, and missed commitments was the useful signal.

Company identity

Five records had null canonical company_id; only the email was directly linked to Consensys. The production canary repaired the incident through company_conversations.

The relationship store may contain multiple extracted entities, including Rho, merchant names, and a duplicate Consensys record. This is acceptable for v1, but alert consumers must verify which company is the supported account. See Conversation-to-company linking plan.

Slack delivery

On August 18, the reassignment Slack action returned:

{
  "posted": false,
  "error": "not_in_channel"
}

The workflow still wrote ticket_reassignment_guideline_alerted_at. This happened after 274 reassignment failures from July 5 through August 22. The required state model is:

detected -> attempted -> delivered -> stamped
                      -> failed -> retryable

Disabled P1 delivery

On August 19 at 20:30 and 21:30 UTC, no-channel-switch classified the email as P1, citing four client-CS exchanges over four business days, the fraud report, and the urgent request for a call. Its agent ran, but no_channel_switch_loop was disabled, so neither Slack action executed. This was recovery evidence, not the earliest intervention.

Jira context

The output FRAUDTM-4046 remains new exposed missing context: it omitted when the issue was created, what Rho requested, and what progress occurred. ENG-2555  and PR #10563  add get_jira_issue_context, backed by organization-scoped synced Jira fields and comments. Synced data keeps workflow reads fast, replayable, and independent of live Jira availability.

Live CS Escalations configuration

Production is live at v57:

Account repeat-contact thresholds

#10 returns one strongest subtype per incident:

It unions conversations.company_id with company_conversations.company_id, counts distinct conversations, includes solved and closed tickets, excludes non-customer and empty-voicemail activity, verifies the supported account and same incident, then posts to #cs-quality-rulebase-alerts before stamping chronic_repeat_contact_alerted_at.

The v57 field writer still receives only anchor_conversation_id, not all related_conversation_ids. This can allow a later related conversation to alert again.

Unresolved follow-up subtypes

#13 no longer requires emotional frustration. It treats calm follow-up such as “We did not receive any update yesterday” as evidence and returns one of:

• missed_promise
• no_response
• repeat_request
• no_meaningful_progress
• re_explanation

Remaining work

1. Replay Consensys against v57.
2. Verify #10 alerts by the third substantive call without treating the requested authorization callback as a failure.
3. Verify #13 classifies the August 18 message as missed_promise.
4. Stamp all related_conversation_ids, not only the anchor.
5. Verify failed Slack delivery does not stamp dedupe.
6. Audit historical precision for #9, #11, and #12 before consolidation.
7. Decide whether no-channel-switch adds independent value.
8. Verify automatic production enqueueing before broad Rho backfill.

The regression passes when account identity resolves, the third substantive contact produces one Slack alert, the missed promise is classified correctly, and failed delivery remains retryable.