Approve what an agent could not close
Rosa takes an offered task, follows it into the case, and finishes it — with the platform checking the one thing it said it would check before she chose how to end it.
This is what a case looks like when it reaches a person. The workforce has already called, already read the documents, and already carried the case as far as its authority goes; what is left is the one decision policy reserved for a specialist. Every screen below is a real screen; every call beside it is what that screen makes.
- Rosa says she is availablepresence is hers to seta person
- The platform offers her one taskwith the reason it chose herautomatic
- She accepts and lands on the casethe task rides alonga person
- She finishes it with proofthe platform verifies its own claima person
Pull the next piece of work
One at a timeOn screen. Rosa is on Start Here. She sets herself available, and presses Get next task — or just the n key.
curl -X POST "$BASE/v1/servicing/tasks/reserve-next" \
-H "Authorization: Bearer $TOKEN" \
-H "LendEasy-Tenant: demo-lender" \
-H "Content-Type: application/json" \
-d '{ "queueCode": "COLLECTIONS" }'{
"taskId": 8802,
"taskTypeName": "Approve an out-of-policy arrangement",
"queueCode": "COLLECTIONS",
"priority": "HIGH",
"caseId": 1001,
"reservationExpiresAt": "2027-05-01T16:12:30Z",
"allocationReason": "Carrying the least work of 4 available eligible workers",
"windowStart": "2027-05-01T09:00:00-07:00",
"windowEnd": "2027-05-01T11:00:00-07:00",
"scheduledZoneId": "America/Los_Angeles"
}The reservation is the offer — there is no separate offered state to reason about. It stands about two minutes on a countdown ring, and allocationReason is the sentence the screen shows her. The borrower’s promised window is kept separate from her internal deadline, because only one of those is a promise made to a person.
If she declines, she picks from a short list phrased about her rather than about the work — I’m busy right now, not my speciality, stepping away, needs someone else.
Accept, and land where the work is
The task follows herOn screen. Accepting does not open a task page for her to read and then navigate away from. It opens case 1001, and the task becomes a ribbon across the top carrying its clock and its finish line. A banner carries the route back.
curl -X POST "$BASE/v1/servicing/tasks/8802/accept" \
-H "Authorization: Bearer $TOKEN" \
-H "LendEasy-Tenant: demo-lender"The case opens with the borrower snapshot docked on the right, the brief telling her what the case needs next, and — because this is a collections matter — what is at stake. Some task types are worked entirely in their own panel instead, and accepting one of those stays put.
Read what finishing it will cost
Told before choosingOn screen. The voice agent has already reached Maya and agreed terms outside the configured bounds. Rosa reads the packaged call, approves the arrangement, and opens Complete. Before she picks anything, each ending states what the platform will verify:
{
"taskId": 8802,
"outcomeCatalogEnforced": true,
"outcomes": [
{
"outcomeCode": "PROMISE_RECORDED",
"displayName": "Arrangement agreed",
"requiresNote": true,
"requiresEvidence": false,
"operationProof": "PROMISE_RECORDED",
"followUpPolicy": "REQUIRED"
},
{
"outcomeCode": "BORROWER_REACHED_NO_COMMITMENT",
"displayName": "Reached, no commitment",
"requiresNote": true,
"operationProof": "INTERACTION_LOGGED",
"followUpPolicy": "OPTIONAL"
},
{
"outcomeCode": "NO_CONTACT",
"displayName": "No answer",
"requiresNote": false,
"operationProof": "INTERACTION_LOGGED",
"followUpPolicy": "OPTIONAL"
}
]
}The screen renders operationProof as a sentence under the option she is hovering: “Checked: an arrangement exists against this case.” She can see, before committing to an answer, that picking Arrangement agreed will only work if she actually recorded one.
There is no free-text status and no other. Where the case is pinned to a particular workflow version, the list narrows further to the endings that version can route onward from.
Finish it
Verified, not assertedcurl -X POST "$BASE/v1/servicing/tasks/8802/complete" \
-H "Authorization: Bearer $TOKEN" \
-H "LendEasy-Tenant: demo-lender" \
-H "Content-Type: application/json" \
-d '{
"outcomeCode": "PROMISE_RECORDED",
"note": "Maya will pay $260 on May 8 and $257.14 on May 22. Confirmed on the call.",
"followUpTaskTypeCode": "CHECK_PROMISE_AFTER_FIRST_DATE"
}'{ "taskId": 8802, "status": "COMPLETED", "outcomeCode": "PROMISE_RECORDED", "caseReEvaluated": true }The platform checks its own claim before accepting the outcome, the case re-evaluates and decides what comes next, and Rosa gets a short receipt with an offer to pull the next task from the same queue — an offer, never a feed.
Had she chosen Arrangement agreed without recording one, the completion would have been refused. She would have known that two screens earlier.
marcus.hale is the checker persona for anything that parks for a second approver, and dana.okoro approves hardship — useful for showing that the preparer cannot approve their own request.