Interactions & channels

Every contact with a borrower — call, email, SMS, chat or letter — is one record carrying why it happened, whether it was permitted, what was sent, whether it arrived, and what came of it. One phone call otherwise produces a task, a compliance decision, a dial attempt, a provider callback, and a note: five records that all sound like the answer to did we contact this borrower. The interaction is the one that answers it — the lasting operational and evidentiary record of the communication itself, with the others linked around it rather than standing in for it.

A blocked interaction is still a record

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.

Six channels, one shared record

Each channel produces its own kind of proof, and the differences are real — a delivery receipt and a recording consent are not the same object. What they share is the part reports and reviewers read:

All channels share case, customer, direction, purpose, participants, identity/authority state, sensitivity, compliance decision, content version, status, outcome, and evidence links.

One contact, several records

For an outbound collection call:

1. A task puts the contact on the voice agent’s queue.
2. A compliance decision evaluates this debt, person, phone, reason, time, and channel.
3. The interaction records the attempted call and content context.
4. Provider events record dial, connect, recording, and completion.
5. 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.

Changing a provider changes nothing public

Provider callbacks enter through closed connector contracts such as POST /v1/servicing/channel-events/{gatewayCode} with X-LendEasy-Gateway-Signature; ordinary clients use normalized interaction routes.

Seven things every outbound interaction names

Each entry is something a reader six months later would otherwise have to guess, and the fifth matters most in a mixed workforce — an interaction that does not say whether a person, a rule, or a model composed it cannot be sampled for quality by any of the three:

• caseId, customer, covered loans or debts, and task when applicable;
• direction, channel, and exact purpose;
• resolved recipient and verified contact detail;
• content template/version or approved ad hoc content hash;
• which worker originated it — the voice or communications agent, a deterministic rule, or a person;
• the execution-time compliance decision; and
• delivery and business outcome.

POST /v1/servicing/cases/1001/scheduled-callbacks
Idempotency-Key: case-HBR-22dpd-callback-01

{
  "windowStart": "2027-05-01T17:00:00-07:00",
  "windowEnd": "2027-05-01T18:00:00-07:00",
  "contactPointRef": "cp_MAYA_MOBILE_1",
  "reasonCode": "COLLECTIONS_FOLLOW_UP",
  "summary": "Borrower asked for an afternoon call about the past-due installment."
}

Future contact is booked as a scheduled callback — a phone promise held as a task on the case, carrying the exact window the borrower was given. The callback’s start-call command owns the current-fact eligibility decision at dial time; the caller cannot supply an earlier decisionId to authorize the call. Scheduled email, SMS, and chat sends are deliberately not offered: a message composed now is sent now, under the at-send gate. POST /v1/servicing/calls/outbound places a live outbound call under the same owned gate — the voice agent on most calls, a person where policy reserves one — the interaction evidence is created before policy runs, and a blocked or failed attempt is returned as 201 with its decisionId and failureCode rather than discarded. POST /v1/servicing/interactions separately records an inbound, outbound, or externally completed interaction.

The interaction point read returns this evidence in place: GET /v1/servicing/interactions/{interactionId} embeds the latest linked compliance decision (complianceDecision with its outcome, hard-stop flag, and per-rule results) and, for phone work, the voiceCall summary with dial authorization, connection timestamps, and recording state — while the dialed number and provider references stay out of the record.

The words spoken are a separate read

Conversation content lives behind two dedicated reads rather than inside the interaction projection:

• GET /v1/servicing/interactions/{interactionId}/transcript
• GET /v1/servicing/interactions/{interactionId}/recording

Both require READ_SERVICING_INTERACTION and the separate sensitive authorization, and both audit the access. They return no-store, short-lived content:

{
  "interactionId": 3001,
  "content": "Redacted example transcript.",
  "contentType": "text/plain",
  "expiresAt": "2027-05-05T18:35:00Z"
}

The recording read returns an opaque short-lived downloadUrl with its contentType and expiresAt instead of inline content. Treat both as issued to one authorized reader at one moment: do not cache the payload alongside the interaction, and do not store the URL as a lasting reference. Requesting again is cheap, and it keeps the access record honest about who read what.

Keeping this content out of GET /v1/servicing/interactions/{interactionId} is deliberate. The interaction record is what a workspace, report, or agent work packet can hold; the words spoken are a separately authorized, separately audited read.

Delivery and business outcomes are different columns

A call that connected and a call that reached the right person are two facts, and only the second one is servicing. Reading the delivery column as the result is how a campaign reports high contact rates while nobody has spoken to a borrower:

Provider-specific strings remain in raw evidence; reports use normalized outcomes.

A blocked voice call permits no email

Fallback is a new interaction attempt with its own contact detail 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.

Several signals in one message

Inbound content can contain several signals at once: a payment question, opt-out, dispute, bankruptcy mention, and attorney representation. Classification preserves every detected signal and creates or links the right matters. A message routed only by what it is mostly about drops the sentence that carried the deadline — and the bankruptcy mention buried under a billing question is exactly the one that had to be acted on first.

An inbound message 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 as the message lands. The interaction preserves the original words or artifact, and a reviewer confirms the structured status where policy requires — protection first, confirmation second, because the reply that was already drafted goes out during the review.

Sensitive content stays out of broad reports

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, where the transcript came from, and redaction status. Storing the version rather than the assumption is what lets a lender show which disclosure a borrower actually received, years after the template was rewritten. Sensitive evidence is not embedded directly in webhook payloads or broad reports, where it would be readable by everyone entitled to a count.