Composite example. Assembled from the shape of real work; all client specifics removed, all numbers invented for illustration.
Source material: RFP (14 pages), kickoff call transcript (62 min), two product screenshots, an email thread with the VP of Servicing Written: 2026-03-02 · Last revised: 2026-03-09
Problem
"Our servicing portal is dated and borrowers call us instead of using it. We need a modern redesign of the account dashboard." — VP Servicing, kickoff call
My reading, not theirs: the dashboard is where the call volume is measured, not necessarily where it is caused. Three of the four call reasons named in the RFP (payment date change, hardship request, payoff quote) are tasks the portal either does not support or completes only partially. A redesigned dashboard that still cannot complete those three tasks will not move call volume.
This reframing is unconfirmed and is question 1 below.
Success metric
| Metric | Baseline | Target | Source |
|---|---|---|---|
| Servicing calls per 1,000 active loans per month | UNRESOLVED | UNRESOLVED | RFP names call deflection as the goal but states no figure; VP said the number "exists in the contact-centre reporting" |
| Self-service completion rate, three named tasks | UNRESOLVED | UNRESOLVED | Not currently instrumented — confirmed on kickoff call |
Guardrail: delinquency rate must not increase. A portal that makes hardship requests harder to find would deflect calls and damage the business.
Note: both primary metrics are UNRESOLVED. The engagement should not proceed past discovery until the contact-centre baseline is produced. Named as question 2.
Users and jobs
| Who | The job they're hiring this for | How we know |
|---|---|---|
| Borrower, current | "Pay this off early and know exactly what it costs me today" | RFP call-reason table, rank 1 |
| Borrower, struggling | "Change my payment date before I miss one" | RFP call-reason table, rank 2 |
| Borrower, curious | "Check that my payment went through" | Assumed from portal analytics summary in RFP — not validated |
| Servicing agent | "Finish the task the borrower couldn't, without asking them to repeat everything" | Kickoff call, VP Servicing |
The agent is a user. The RFP does not treat them as one.
Constraints
| Constraint | Kind | Confirmed by |
|---|---|---|
| Payoff quotes are generated by a nightly batch, not on demand | data | Lead engineer, kickoff call |
| Hardship requests require a compliance-reviewed disclosure flow | compliance | RFP §4.2 |
| Must support the existing SSO; no new account creation | platform | RFP §6 |
| WCAG 2.2 AA is contractual | compliance | RFP §7.1 |
| Design complete by end of Q3 | timeline | Kickoff call |
Unconfirmed, needs an engineer: whether payment-date changes can be committed in-session or are queued; what the servicing API returns when a loan is mid-transfer; whether agent and borrower views share a data layer.
Assumption register
Sorted by cost of being wrong, descending.
| # | Assumption | Owner | Cost if wrong | Cheap to test? | Status |
|---|---|---|---|---|---|
| 1 | Call volume is caused by missing capability, not by dashboard design | VP Servicing | The entire engagement solves the wrong problem | Yes — one afternoon in contact-centre call reasons | OPEN |
| 2 | Payoff quotes can be shown same-day | Lead engineer | The top-ranked task cannot be completed in-portal; flow needs a "quote requested" state instead | Yes — one conversation | OPEN |
| 3 | Borrowers will complete a hardship request unaided | VP Servicing / Compliance | Vulnerable users abandon mid-flow at the worst possible moment | No — needs research | OPEN |
| 4 | Agents can be given the same interface as borrowers | Unassigned | A whole second product appears in week six | Partly | OPEN — needs an owner |
| 5 | The existing SSO supports step-up auth for payoff | Lead engineer | Security redesign mid-project | Yes | OPEN |
The three questions
- Can we see the contact-centre call-reason breakdown for the last two quarters? It decides whether this is a redesign or a capability gap — and that changes the shape of the entire engagement.
- What is today's baseline for the metric we are being asked to move, and who owns producing it?
- Is the servicing agent in scope? If yes, that is a second product and the timeline needs to reflect it. If no, we should say so in writing now.
Out of scope
Origination. Mobile apps (responsive web only). Anything requiring a new core-system integration. Agreed on the kickoff call, recorded here so it is not reopened in month three.
Open — unresolved
- Both primary metrics have no baseline.
- No analytics access granted yet; all behavioural claims in the RFP are unverified.
- No borrower research exists. Every statement about borrower intent in this document is an assumption, including mine.
- Assumption 4 has no owner.