On this page
A condition that depends on a third party can look open long after the team has done its part. The appraiser has the order, the title company has the request, and the employer has the verification form. Without a due-date note, the file shows only that something is missing, and the next reviewer cannot tell whether to wait, call, or escalate. A good note makes the dependency and the next checkpoint visible.
Name the dependency and the owner
Start the note with the condition and the party responsible for the next action. The party may be an appraiser, a title officer, an employer, a borrower, or another lender. Naming the party prevents the team from treating an external wait as an internal task. It also tells the reviewer who to contact when the date passes.
Record the name of the person or team at the third party, not only the company. A note that says waiting on the title company is weaker than one that names the closing officer and the request number. The named contact makes follow-up possible without reopening the original email thread. If the team does not have a name, the first action is to get one.
Assign an internal owner who watches the dependency. The internal owner does not perform the third party's work, but they confirm the request was received and follow up on the promised date. That distinction keeps the file moving without pretending the team controls the vendor. The mortgage operations support lead can define who owns each vendor category.
Record what was requested and when
The note should state exactly what the team asked for, the date and time of the request, and the channel used. A vague request produces a vague response, and a reviewer cannot tell whether the third party received the right instructions. Copy the request reference or the order number when one exists. Attach the reference to the request so the note and the source stay linked.
Include the response deadline the third party acknowledged. If the vendor promised a report by a date, write that date in the note. If the vendor gave no date, record the team's expected date and mark it as an estimate. The difference matters when the file is reviewed or when a borrower asks for an update.
Keep the original request and the note linked. A later reviewer may need to see the exact wording, especially when the condition is disputed. The note can summarize, but the source should remain available. A summary without a link is an assertion, while a summary with a link is evidence.
Set a follow-up date before the due date
A due date is not a follow-up plan. Add a checkpoint a day or two before the deadline so the team can act before the condition is late. The checkpoint should name the action, such as calling the vendor or checking the portal, and the person who will do it. A checkpoint that only says monitor is not a task.
Use a short escalation ladder for missed checkpoints. The first step is a direct call to the named contact. The second is a message to the vendor's supervisor or account manager. The third is a decision by the internal owner about an alternative, such as a different vendor or a borrower conversation. Write the ladder in the note so the next person does not invent one.
Do not escalate every dependency on the same day. The ladder should match the risk to the closing date. A condition with two weeks of runway can wait for a normal follow-up, while one with two days needs a same-day call. The note should show the runway so the owner can choose the right step.
Tell the borrower what is happening
A third-party delay is a common source of borrower anxiety. The note should record the last borrower update and the next one. If the team has not told the borrower about the dependency, the note should flag that as an open action. Silence invites the borrower to call a different contact for information.
Use approved language that states the dependency without blaming the vendor. A sentence that says the appraisal is with the assigned appraiser and the team will confirm the date on a specific day is clearer than a general apology. The borrower communication support workflow can supply the template and the escalation path for questions. Keep the template short and let the processor add the specific detail.
Do not promise a date the third party has not confirmed. If the vendor gave a range, tell the borrower the range and the date the team will update again. A missed promise damages trust more than an honest range. Record the exact wording so the next person can continue the conversation without contradicting it.
Close the note with evidence
When the third party responds, the note should record what arrived, when, and whether it satisfies the condition. A vendor email that says the report is complete is not the same as a report in the file. The internal owner should confirm the document is present and readable before closing the condition. Record the date the document was checked, not only the date it arrived.
If the response does not satisfy the condition, reopen the note with the specific gap. A title commitment that omits an exception is different from one that is merely late. The note should show the gap and the new request, not only a new due date. Otherwise the file cycles through the same incomplete response.
Keep the closed note with the file for the review period. The record shows the dependency, the follow-up, and the evidence, which is useful when a later reviewer asks why a condition took several days. The note is also a source for the monthly vendor review, where the team can see which third parties consistently miss their dates. A later reviewer should be able to see the dependency and the evidence without opening the whole thread.
Review dependencies for repeat problems
Collect the notes for a month and count late responses by third party and condition type. A vendor that misses dates on one document type may need a different contact or a clearer request. A condition type that repeatedly waits on the borrower may need a better explanation at the start. The pattern is more useful than any single escalation.
Share the counts with the team and with the vendor contact when appropriate. A short conversation about the missed dates can improve the next order without a formal complaint. Record the change in the vendor note so the next processor knows what was agreed. The Federal Housing Administration's Single Family Housing Policy Handbook is one reference for program-specific requirements, though the team should confirm the applicable investor rule.
Review the note format after a few weeks and remove any field that nobody uses. A due-date note should be short enough to write in five minutes and specific enough to survive a handoff. The goal is a file that shows what the team is waiting for, who is responsible, and when the next check will happen. A note that takes too long to write will be skipped during a busy week.