Who owns the next step in a credit workflow?
A loan application can look complete while the work is stuck between people. Model each state with an owner, an expected next action and an exception path before optimizing for speed.
On this page 5 sections
- Separate a record's status from the work someone still needs to do.
- Give every waiting state an owner, trigger and escalation path.
- Measure time between handoffs as well as total completion time.
A status label can make a lending workflow look orderly while nobody knows who should act next. “Pending” may mean the applicant owes a document, an operations team is checking it, a decision-maker has not reviewed it, or an external dependency has not responded. Those are different states wearing the same word.
The product problem is not merely to make the application form shorter. It is to make responsibility and the next move visible across the people and systems that carry the case.
Model work, not just records#
A loan application is a record, but the workflow is a series of actions: information is supplied, checked, resolved, reviewed, and eventually closed or continued. The states should describe what is happening to the work, not just how much information is present in the form.
For every state, write down:
| Question | Example answer |
|---|---|
| Who owns the next action? | Applicant, operations reviewer, or decision owner |
| What triggers it? | A missing field, a submitted document, or a completed check |
| What evidence is required? | The specific information needed to move forward |
| What happens if it cannot proceed? | A named exception route and a visible reason |
If any cell is blank, the status is likely to become a parking lot. “Waiting for review” is not an operational state if the system cannot identify the queue, owner, or next event.
Separate missing information from review#
A request for a document and an internal verification are not the same kind of wait. The first needs a clear ask to the applicant; the second needs a work queue and an owner. Combining them creates unhelpful notifications and makes it difficult to know whether the customer or the institution has the next move.
Use distinct states such as “information requested,” “information received,” and “under review,” but only if the people operating the workflow can act on those distinctions. Each state should have a transition rule and an exit condition. If the product cannot tell whether a document is sufficient, it should not automatically label the case “complete.”
Show the reason for the wait in language the relevant person can use. “More information required” is weaker than “Please provide the page that shows the requested repayment date.” The exact wording depends on the process; the rule is that the request must name the missing evidence and what will happen after it arrives.
Design the exception path before the happy path is polished#
A workflow designed only for a complete, legible application will push exceptions into email, spreadsheets, and memory. That is where ownership becomes ambiguous and the product loses its record of why a decision was delayed.
List the exceptions that alter the next action: unreadable information, conflicting values, duplicate submissions, a deadline that has passed, or a case that needs a human review. For each, specify who receives it, what they can decide, and what evidence they must leave behind.
Do not turn every exception into a free-text comment. Free text can capture nuance, but it does not reliably route the work. Pair it with a small set of structured reasons and a clear escalation owner. If the situation does not fit the list, capture the explanation without pretending the case is in a known state.
Measure the handoffs#
A single end-to-end duration can hide where the workflow is stuck. Measure the time between meaningful handoffs: request to submission, submission to review, review to decision, and decision to communication. State the start and end event for each interval so that a dashboard does not compare incompatible clocks.
Then segment by case type or route only when those distinctions are supported by the data and useful to an operating decision. A long wait caused by missing information may need better instructions. A long internal review may need queue ownership or policy clarification. Averages can obscure a small group waiting far longer; inspect the distribution and the oldest open cases as well.
Do not optimize elapsed time by hiding necessary checks. In a financial workflow, speed is valuable only if the product preserves the evidence and review required for a sound decision. Make the speed measure sit beside the quality and exception measures, not in place of them.
Make the next step legible to every participant#
Applicants need to know whether to act, what to provide, and whether their submission was received. Operators need a queue they can work and a record of what is outstanding. Decision-makers need the evidence and the unresolved questions, not a green badge that implies certainty.
That does not mean every participant sees every field. Permissions and data minimization still matter. Design the workflow so each role sees enough to perform its action and no more than the role requires.
A handoff also needs a time expectation. “Assigned” does not tell an operator or applicant when the next update should arrive. Define the expected review window, what message appears if that window is missed, and who can unblock the queue. Do not promise a decision time the team cannot control; distinguish an internal target from an external dependency. This makes delays visible without implying that every case should follow the same path.
A useful prototype can be a state-transition table before it is a new screen. Put one ordinary case and two exceptions through it. For each transition, check that the owner, trigger, permission, notification and audit record are explicit. If the next move cannot be answered from the product, fix the workflow model before polishing the dashboard.