Report delivery is the last step, and the status model is what surrounds it. An assignment moves through ordered, assigned, scheduled, inspected, in review, and delivered. Clients should see some of those and not others, because an internal review state exposed to a lender invites a conversation the process is not built to have mid-stream. A delivery system publishes the milestones you choose, collapses the rest to the last published state, transmits the report in the formats each client requires, and records what went out, to whom, and when.
Why clients call to ask where the report is
Status is a person, not a field
The client emails, the coordinator asks the appraiser, the appraiser answers when they are off the road. Two people spend time producing an answer the system already knew at nine that morning.
The same order shows different states in different places
The client portal says in progress. The internal board says inspected. The appraiser believes it went to review yesterday. All three are partly right and none of them is authoritative.
Internal review states leak to the client
A feed that exposes in revision or returned to appraiser invites a call about a report that has not been delivered. Review is internal work, and there is no useful client conversation to be had about it while it is underway.
Delivery is an email attachment with no record
The report goes out of somebody’s mailbox. Whether the XML went with the PDF, whether the client received it, and which version they are holding are all unanswerable a month later.
Format requirements differ by client and get missed
One client needs PDF plus MISMO XML. One needs upload to their own portal. One needs the invoice packaged with the report. The requirement lives in a coordinator’s memory until a delivery bounces back.
Status model and client visibility by milestone
A handful of published states, several internal ones, and a deliberate decision about which is which. The third column is the one worth arguing about internally before the build starts, because it is hard to walk back once clients are used to it.
| State | What it means internally | Published to the client | What the client sees |
|---|---|---|---|
| Ordered | Request received, not yet accepted or fee-confirmed | Yes | Order received, with the order number and the product requested |
| Accepted | Fee, scope, and due date confirmed; competency and conflict questions settled | Yes | Accepted, with the confirmed due date |
| Assigned | A specific appraiser holds the assignment | Configurable per client | Assigned. Some clients see the appraiser name and license number; others see only the state |
| Scheduled | Inspection window confirmed with all parties | Yes | Scheduled, with the date and window where that client is permitted to see it |
| Inspected | Property accessed, date of inspection recorded | Yes | Inspected, showing the recorded date |
| Report drafted | Appraiser has completed a draft | No | Remains at Inspected |
| In review | Internal review underway | No | Remains at Inspected |
| Returned to appraiser | Review identified something to address before delivery | No | Remains at Inspected |
| Delivered | Report and required files transmitted to the client of record | Yes | Delivered, with the timestamp and the files that were sent |
| Revision in progress | A post-delivery request is being worked | Yes, as its own state | Revision requested, since the client raised it and already knows |
| On hold: access | No access achieved, waiting on rescheduling | Yes | On hold pending property access, with the reason |
| On hold: client | Waiting on the client for information or a document | Yes | On hold pending client, naming what is needed |
The wiring under the status view
One state machine, one source
States live on the assignment record and change only through defined transitions. The client view, the internal board, and any client-side feed all read the same field, which is the only way to keep them from disagreeing.
Transitions triggered by the work itself
Inspected is set when the appraiser marks the property inspected in the field. Delivered is set when the transmission completes. Nobody maintains a status field as a separate chore, which is why it stays true.
Delivery packaged per client
PDF, MISMO XML, the invoice, and any client-specific attachments are assembled to that client’s requirement and transmitted the way that client accepts: portal upload, secure link, or email with a receipt captured.
Delivery recorded as an event
What was sent, in which formats, to which recipients, at what time, and which report version. A redelivery is a new event rather than an overwrite, so the history shows every copy that ever left the firm.
A client view without login friction
A status page reached from a link on the order confirmation, scoped to that order only. Clients who prefer a feed into their own system get one instead, reading the identical underlying states.
What the status layer reads from
- CRM and HubSpot automation — Order status and delivery events land on the client record, so whoever owns the relationship sees the same picture.
- custom application development — The internal board and the client-facing status view, built to your own state model rather than a generic one.
- document packaging and versioning — Report versions and the file package each client requires at the moment of delivery.
Is this a fit for your business?
A good fit when
- Clients ask for status often enough that someone answers those messages all day
- You deliver different file packages to different clients
- Your internal board and what clients see have drifted apart
- You want a delivery record showing exactly what went out and to whom
Probably not a fit when
- You deliver every report through one AMC portal that already provides client status
- You want a status feed that predicts a completion date on its own
- You carry only a handful of open assignments at a time
What to have ready
- The states you actually use today, including the informal ones
- Delivery format and channel requirements per client
- A decision, or a willingness to make one, about which milestones clients see
Questions we get asked
Should clients see the appraiser's name?
It depends on the client and your arrangement with them. Lenders and AMCs generally already know, and non-lender clients usually want to. Some firms prefer to keep panel appraiser identity off a self-service view to control direct contact. That is why it is a per-client setting rather than a global one.
Does the client see the due date change?
They see the current committed due date and any hold state with its reason. What they do not see is an internal target that moves as work shifts around. Publishing a date that quietly moves is worse than publishing a hold, which at least says something true about the file.
Can we deliver into a client's own portal automatically?
Sometimes. Where a client offers an interface for submission, delivery can run end to end. Where they do not, the system assembles the exact package and prompts a person to upload it, then records the delivery once they confirm. The delivery event is captured the same way in both cases.
Does the status view show anything about the value?
No. Status covers where the assignment sits in the process: ordered, scheduled, inspected, delivered, on hold. Nothing in the status layer references the conclusion, a range, or any indication of where a report is heading. The report is the only place a value appears, and it appears when the report is delivered.
Related
- appraisal invoicing and payment at delivery
- revision request and rebuttal tracking
- CRM and HubSpot automation
- workflow automation for appraisal firms
Tell us what the process looks like now and we will map what a system would need to do. No obligation, and you keep the map either way.