# Phase 7 · Operate with accountability

## A marketplace becomes trustworthy through its working habits

The first six phases make a lending journey understandable. Phase 7 asks whether a real team could operate that journey on a busy Monday morning without relying on memory, private spreadsheets or one heroic administrator.

This is the operations phase. It is where ClearLend turns exceptions into visible work, sensitive actions into controlled decisions and history into something a customer, manager or auditor can understand.

The people are familiar: **Alex**, the borrower, wants a clear answer; **Sam**, a funding partner, wants confidence that capital is handled properly; **Jordan**, an operations specialist, needs a queue that tells them what to do next; and **Priya**, an approver or oversight lead, needs evidence that the right person made the right decision.

## The question behind the interface

“Operations” does not mean a larger dashboard. It means answering five practical questions for every important case:

1. What needs attention?
2. Who is responsible for the next step?
3. What authority is required?
4. What evidence supports the decision?
5. What changed, when and why?

### One case, three useful views

| Person | What they need | What ClearLend should avoid |
| --- | --- | --- |
| Borrower | A plain-language status, request and next action | Internal queue labels or unexplained silence |
| Operations specialist | A prioritised queue, ownership, evidence and due date | Searching across unrelated screens |
| Oversight lead | Trends, exceptions, audit history and policy breaches | Reports with unclear definitions or stale numbers |

The same underlying event should be explained differently without changing its meaning.

## Work queues are promises about attention

A queue is not just a list of records. It is a promise that a case has a named owner, a meaningful status and a next action. A useful queue item might include:

- case and customer reference;
- reason it entered the queue;
- severity and service target;
- current owner and team;
- evidence already checked;
- next action and due date;
- links to related payment, repayment or decision events.

For example, an unknown payment should not sit beside an ordinary information request with identical priority. It may require provider evidence, a reconciliation decision and a customer update. The queue makes that work explicit.

## Separate preparation, approval and oversight

ClearLend should make authority visible in the workflow. A person may prepare a payment, but a policy may require another person to approve it. An operator may correct a customer-facing explanation, while only an authorised role can record a financial adjustment. An oversight user may inspect the history without being able to change it.

This separation protects customers and the team. It also gives Afzal a strong engineering story: permissions are expressed at the action boundary, checked against the record and recorded with the result. A hidden button is not a security model.

## Permission is a decision with context

Access should consider more than a job title. The policy may depend on:

- the person and their role;
- the organisation or team they belong to;
- the record’s ownership and sensitivity;
- the action being requested;
- approval limits and conflict-of-interest rules;
- whether the record is open, closed or under investigation.

The API should return a useful explanation when an action is refused. “Not permitted for this case” is safer and more helpful than a silent button or a generic error. The interface can then guide the user to request help without revealing information they should not see.

## Audit history should tell a story

An audit record is valuable when another person can reconstruct the decision later. It should identify the actor, action, time, affected record, reason, previous and new state where appropriate, and the source of the request. A display label such as “status changed” is not enough to explain why a payment was marked resolved.

Audit history is different from an application log. Logs help engineers diagnose a service; an audit trail explains a business action. They may share correlation identifiers, but they have different retention, access and presentation needs.

## Reporting needs definitions before charts

Operations reporting should define every number. “Overdue loans” needs a due-date rule, a time zone, a treatment for unknown payments and a correction policy. “Average time to decision” needs a start event, an end event and a decision about paused cases.

Useful first reports include:

- cases approaching or missing their service target;
- unknown payment outcomes by age and owner;
- applications waiting for information;
- repayment arrears by agreed category;
- actions completed outside the normal approval path;
- audit or permission exceptions.

Each report should show its last refresh time and source. That small detail prevents a polished chart from being mistaken for live truth.

## A guided operational scenario

Imagine an outgoing payment times out after the provider may have accepted it, while the same borrower has an instalment due tomorrow. Jordan sees two linked work items: payment investigation and servicing watch. The payment item is high priority because a duplicate release is possible. Jordan gathers provider evidence but cannot resolve the outcome alone; Priya approves the final decision. Alex receives a plain-language update that the payment is being checked. Sam sees exposure unchanged until a confirmed event is recorded.

That scenario demonstrates the value of connected operations: a queue, a permission boundary, a linked audit story and audience-specific communication work together.

## Senior ASP.NET engineering judgement

Afzal’s role here is to keep operational rules explicit and testable. Commands should enforce authorisation at the application boundary, query models should expose only the fields a role needs, and background jobs should be observable without becoming a second source of business truth. The design should support correlation IDs, structured logs, health checks, durable work items and a clear retention policy.

The implementation should also resist accidental complexity. A small, well-defined work-item model with state transitions is easier to review than dozens of hidden flags. A policy service with named decisions is easier to test than scattered role checks in controllers and templates.

## Evidence that Phase 7 is complete

- A work queue shows owner, reason, priority, due date and next action.
- A borrower, operator and oversight user receive appropriately scoped views.
- Preparation and approval are separate for a controlled action.
- A refused action leaves no financial state change and produces a useful explanation.
- Audit history can reconstruct a decision without reading application logs.
- Reports document definitions, source and freshness.
- A scenario test covers an unknown payment, an overdue repayment and an escalation.

## Guided practice

Design two queue items: an unknown £5,000 release and a repayment three days overdue. Give each item an owner, service target, evidence checklist and escalation path. Then describe what Alex, Sam, Jordan and Priya can each see. Finally, write one audit record for the moment Priya resolves the payment and explain which report should include it.

The goal is not to create the largest operations console. It is to make responsibility, authority and evidence obvious enough that the marketplace can grow without losing trust.