A revision request is anything a client sends back after delivery: a missing signature, a typo in the borrower name, a request to address a comparable that was not discussed, or a challenge to something the report concluded. Treating them as one queue is why they get lost. A tracking system classifies each request on arrival, starts a response clock, routes it to administrative staff or to the signing appraiser depending on class, and records the outcome. Whether a substantive request changes anything in the report is the appraiser’s determination.
What an untriaged revision queue does to a file
Everything lands in one inbox as revision needed
A missing page number and a challenge to the adjustment grid arrive in the same queue under the same subject line. The one needing the appraiser and the one needing an assistant are indistinguishable until somebody opens both.
The clocks are different and neither is tracked
Client expectations differ by request type and by client. Without separate clocks, the aging report produces one number that means nothing, and the request that actually carried risk is the one that sat the longest.
Repeat rounds on the same report are not connected
A second and third round come back on the same file. Each is worked as a fresh email. Nobody sees that this report has been through three rounds with the same reviewer until the appraiser raises it.
The appraiser's response is not retained with the assignment
The appraiser replies by email explaining why a suggested comparable was not used and what the data showed. That reasoning belongs with the assignment, and instead it lives in one person’s sent-items folder.
Substantive challenges get handled like clerical fixes
Someone edits the report so the request goes away. That is exactly the wrong instinct, and it is what a queue invites when it does not distinguish a correction from a challenge to a conclusion the appraiser signed.
Revision log schema, split by request class
One log, two classes, different fields and different clocks on each. The split is what lets administrative staff clear the first class quickly without ever putting a conclusion in front of the wrong person.
| Field | Clerical correction | Substantive request | Why the two are kept apart |
|---|---|---|---|
| What it covers | Typos, missing signature or exhibit, wrong loan number, transposed address, formatting, missing page | Requests to address an additional comparable, reconcile a condition rating, respond to a data discrepancy, or explain a stated conclusion | The work is different and so is the person qualified to do it |
| Who receives it | Administrative or review staff | The signing appraiser, always | Anything the report concluded is revisited only by the person who signed it |
| When the clock starts | On receipt | On receipt, pausing only when the requester has been asked for specifics and has not answered | A pause with a stated reason is honest; a clock that never pauses gets ignored by everyone |
| Clock target | Set per client, usually the shorter tier | Set per client, longer, and reported separately | One aggregate number hides the requests that carry the most exposure |
| Required at intake | The specific item and where it appears in the report | The page or section, what the requester believes is deficient, and any data or documents relied on | A substantive request with no specifics cannot be answered and should go back for detail |
| Permitted outcomes | Corrected and redelivered, or not applicable with a note | Report revised with the reasoning stated, or no change with the reasoning stated | Both outcomes are legitimate and the log has to be able to record either one |
| What is retained | The request and the corrected report version | Request, supporting material, the appraiser’s written response, and the resulting report version if one issued | This is the part that answers a question asked a year later |
| Round tracking | Counted per report | Counted per report and shown on the assignment record | A third round on one file is a signal, not a coincidence |
How the revision workflow is put together
One door for revisions
Requests arrive through a form or a monitored address that creates a logged item rather than an email. The form asks for the class, the page or section, and the specifics, so triage happens at the moment of arrival instead of the next morning.
Classification with an override that is recorded
The requester’s selection is a starting point. Review staff can reclassify, and the change is logged with who made it. A client marking a challenge to a conclusion as clerical does not make it clerical.
Routing by class rather than by who is free
Clerical items go to the administrative queue. Substantive items go to the signing appraiser’s queue and nowhere else. The two queues are separate views, so neither one hides inside the other on a busy week.
Clocks that pause visibly
When a request goes back to the requester for specifics, the clock pauses and the reason sits on the record. When they answer, it resumes. The aging report separates your firm’s time from the requester’s time.
Version control on the report itself
Each redelivery is a new version carrying its own date, with the prior one retained. The log links a request to the version it produced, or records that no revision resulted and states why.
What the revision log connects to
- document versioning and retention — Report versions retained with dates, so a redelivery never overwrites what was previously delivered.
- form automation for structured requests — The revision request form that forces specifics instead of accepting a one-line email.
- workflow automation for queues and clocks — Routing by class, clock management with visible pauses, and escalation on aged items.
Is this a fit for your business?
A good fit when
- You deliver to lenders or AMCs whose reviewers send requests back regularly
- Revision requests currently arrive as email and get worked out of an inbox
- You want to see how many rounds a report has been through before the fourth one
- You need the appraiser’s written response retained with the assignment
Probably not a fit when
- You produce non-lender reports almost exclusively and revisions are rare
- You want a system that drafts responses to substantive requests
- You are looking for guidance on how to answer a particular challenge
What to have ready
- How revision requests reach you today, per client
- Your current response expectations by client and by request type
- A handful of recent requests, ideally a mix of clerical and substantive
Questions we get asked
Who decides whether a request is clerical or substantive?
The requester picks first, because they know what they are asking for. Your review staff can reclassify and the change is logged. In practice the boundary is clear: if answering it requires reconsidering anything the appraiser concluded, it is substantive and it goes to the appraiser.
Can the system handle routine requests on its own?
It handles the mechanical part of clerical items: pulling the correct version, applying a missing signature, redelivering, and notifying the requester. It does not draft or send responses to substantive requests. Those are the appraiser’s words and judgment; the system routes the request and retains the reply.
What happens when a client keeps sending the same request back?
The round counter makes it visible, and an escalation rule puts it in front of whoever manages that client relationship. The log shows what was asked each round, what was answered, and whether anything changed, which is a better basis for that conversation than two people’s memories.
Does this replace our internal review process?
No. Review before delivery and revision handling after delivery are different functions. This tracks what comes back once a report has left and keeps the response attached to the assignment. It does not change how your reviewer works ahead of delivery.
Related
- reconsideration of value request workflow
- report delivery and client status visibility
- document workflow and version retention
- 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.