Interactions & channels
Record every inbound and outbound communication with reason, eligibility decision, content version, delivery state, outcome, and evidence.
An interaction is the operational and evidentiary record of communication. It is not interchangeable with a task, channel-provider event, call attempt, or free-form note.
Lifecycle
Inbound interactions start from a provider or operator event, link or create the appropriate case, and record verification level before sensitive account details are disclosed.
One contact, several records
For an outbound collection call:
- A task tells a worker to attempt contact.
- A compliance decision evaluates this debt, person, phone, reason, time, and channel.
- The interaction records the attempted call and content context.
- Provider events record dial, connect, recording, and completion.
- The interaction outcome may complete the task, schedule follow-up, or create a promise action.
This separation makes provider retries and task reassignment harmless to the communication record.
Required context
Every outbound interaction names:
caseId, customer, covered loans or debts, and task when applicable;- direction, channel, and exact purpose;
- resolved recipient and verified contact point;
- content template/version or approved ad hoc content hash;
- originating worker type—human, deterministic automation, or AI session;
- the execution-time compliance decision; and
- delivery and business outcome.
POST /v1/servicing/interactions
Idempotency-Key: case-HBR-22dpd-call-01
{
"caseId": "case_HBR_COL_51",
"direction": "outbound",
"channel": "voice",
"purpose": "collections",
"contactPointId": "cp_MAYA_MOBILE_1",
"content": { "scriptVersion": "collections-opening-v5" }
}The API re-evaluates eligibility during execution. Supplying an earlier decisionId links context but does not authorize the call.
Outcomes by channel
| Channel | Delivery outcomes | Business outcomes |
|---|---|---|
| Voice | connected, no answer, voicemail, busy, invalid number, failed | verified party reached, third party reached, wrong number, promise discussed, dispute raised |
| delivered, bounced, deferred, complained, failed | response received, document viewed, opt-out received | |
| SMS | delivered, undelivered, blocked, failed | reply received, opt-out received, link completed |
| Secure message | published, viewed, expired | response received, document supplied |
| produced, handed to carrier, returned | delivery evidence received, address invalidated |
Provider-specific strings remain in raw evidence; reports use normalized outcomes.
Channel fallback
Fallback is a new interaction attempt with its own contact point and compliance decision. If voice is blocked because the local time is inconvenient, that result does not prove SMS or email is allowed. A workflow can recommend the next channel only after testing its own consent, opt-out, purpose, content, and timing rules.
If no route is eligible, the case moves to a named waiting or review state with the blocking reasons. It never reports “contact attempted” when execution stopped at the gate.
Inbound protected signals
Inbound communications can change controls immediately. A cease request, bankruptcy notice, dispute, identity-theft assertion, legal-representative notice, servicemember request, or payment-authorization revocation creates structured facts and specialist work. The interaction preserves the original words or artifact, but a reviewer confirms the structured status where policy requires.
Content and evidence
Template rendering stores the template and legal-content versions, merge facts with source times, final rendered hash, and delivery artifact. Voice stores script version, recording references and access policy, transcription provenance, and redaction status. Sensitive evidence is not embedded directly in webhook payloads or broad reports.