A reconsideration of value is a request that the appraiser reconsider the value conclusion in light of information the requester believes was missing, inaccurate, or not considered. It is not a negotiation and it is not an instruction. A workflow system collects the request in a structured form with the required specifics, routes it to the signing appraiser with the original wording intact, tracks the response window, and records the determination and the reasoning whether or not the conclusion changes. The determination itself belongs entirely to the appraiser.
Where ROV handling comes apart
The request arrives with nothing to act on
An email says the value came in low and asks for a second look. No addresses, no data, no statement of what is believed deficient. The appraiser cannot act on it, and the requester believes the ball is in your court.
It routes to whoever opened the email
A processor forwards it, a coordinator forwards it again, and by the time it reaches the appraiser the original context and the date it arrived are gone. So is any sense of how long the clock has run.
Nothing captures the outcome when the value does not change
The appraiser considers the material and concludes no change is warranted. That conclusion and the reasoning behind it get communicated on a call or in a two-line email, and never land in the assignment file.
How the request was worded is not preserved
Requests occasionally arrive with language that goes past presenting information. Whether such language was received, what it said, and how the firm handled it is exactly what should be on the record and usually is not.
Repeat requests are neither counted nor capped
Client and investor guidelines commonly limit borrower-initiated requests per report and cap how many alternative sales may be submitted. With no counter, those limits are enforced by whoever remembers them.
ROV intake requirements and the record left behind
Two halves of one artifact. The middle column is what a request must contain before it is accepted as a request at all. The right column is what the assignment file holds once it closes, whatever the outcome.
| Element | Required on intake | Recorded on completion |
|---|---|---|
| Requesting party and role | Named requester, their role, and the client of record they act for | The same, with the date and the channel the request arrived through |
| Basis of the request | Which basis applies: information believed missing, data believed inaccurate, or sales believed not considered | The basis as submitted, alongside the appraiser’s response to each point raised |
| Report references | The page or section of the report the request addresses | The same references, tied to the report version in effect when the request arrived |
| Alternative sales offered | Address, sale date, sale price, and source for each, up to the number your client policy permits | Each sale listed with the appraiser’s written consideration of it |
| Supporting documents | Anything the requester relies on: listing sheets, permits, inspection reports, a prior appraisal | Retained with the request in the assignment file |
| Original wording | Captured verbatim, never summarized by the person who received it | Verbatim text retained, with anything your firm flags routed per your own policy and the flag on the record |
| Request count | Checked against the per-report cap in force for that client | Round number, plus the outcome of every prior round on the same report |
| Response window | Started only on acceptance of a complete request | Start, any documented pause, and the date the response was issued |
| Appraiser determination | Not requested at intake and not previewed anywhere | Revised report with the reasoning, or no change with the reasoning, in the appraiser’s own words |
| Response delivery | Not applicable | Who the response went to, when, and which report version was delivered if one was |
Building the ROV path
A dedicated intake form, separate from revisions
An ROV is not a revision request, and mixing the two hides both. The form asks for the basis, the report references, and any alternative sales in structured fields, so an incomplete request is caught before it consumes anyone’s afternoon.
Completeness check before acceptance
A request missing sale dates, sources, or a stated basis goes back to the requester with the gaps named. The response window does not start on an incomplete request, and the return is logged with its date.
Direct routing to the signing appraiser
The request reaches the appraiser who signed the report with the original text and attachments intact. No summarizing, no relay through three people, no rewriting of what the requester said.
A response the appraiser writes
The appraiser addresses each point and each offered sale and states the determination. The system supplies structure and retention only. It does not draft the response, propose language, or carry any field that could stand in for the appraiser’s judgment.
One record, closed either way
No change and change are both closed states with equal standing. The file holds the request, the supporting material, the response, the report version if one issued, and the delivery record.
Systems involved in an ROV
- form automation for structured intake — The ROV intake form, the completeness check, and the return-for-detail path back to the requester.
- document retention and assembly — Retention of the request, its attachments, the appraiser's response, and any resulting report version.
- workflow automation for routing and windows — Routing to the signing appraiser, the response window, escalation, and the per-report round counter.
Is this a fit for your business?
A good fit when
- You appraise for lenders or AMCs and receive borrower-initiated requests
- ROVs arrive by email today with no consistent required content
- You want the appraiser’s reasoning retained whether or not the conclusion changed
- You need to show how a request was received and handled, on demand
Probably not a fit when
- You do no lender work and ROVs are not part of your practice
- You want software that assesses whether a request has merit
- You are looking for someone to tell you what your ROV policy should say
What to have ready
- Your client and investor requirements for ROV handling, including any caps
- The channels ROVs reach you through today
- Who signs reports, and who owns the client relationship for escalation
Questions we get asked
Does the system ever tell the appraiser what to do with a request?
No, and it is built so that it cannot. There is no recommendation field, no scoring of offered sales, and no suggested outcome. The workflow moves a complete request to the signing appraiser and holds whatever that appraiser writes back. Anything beyond that puts a system where it has no business being.
What if a request contains language that looks like pressure?
The wording is retained verbatim rather than summarized, and the item can be flagged for review by whoever handles that at your firm. What counts as improper, and what you are obligated to do about it, is a matter for your compliance staff and your counsel. The system guarantees only that the original wording, the sender, and the timestamp are still there when someone looks.
Can we cap how many ROVs one report receives?
Yes. The cap is a per-client setting, since client and investor guidelines differ on how many borrower-initiated requests a report may receive and how many alternative sales may accompany one. An over-cap request routes to a person rather than being silently rejected.
How is this different from a revision request?
A revision request covers corrections and requests to address something in the report. An ROV asks the appraiser to reconsider the value conclusion itself. They need different intake fields, different routing, and different retention, which is why we build two workflows that never share a queue.
Related
- revision request and rebuttal tracking
- report delivery and client status visibility
- form automation for structured intake
- 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.