Reverse mortgage LOS reference check questions: a worksheet
Use a workflow question register and a fictional reference example to separate firsthand experience from unresolved LOS evaluation questions.
In this article
Reverse mortgage LOS reference check questions should uncover how a comparable team actually works, where its experience differs from yours, and what remains unverified. After a loan origination system (LOS) demo, use a reference conversation to test assumptions about implementation ownership, exception handling, and adoption.
This worksheet helps lender executives and procurement sponsors organize those questions. It proposes a method for evaluating references, not a customer testimonial, a vendor ranking, or evidence of ReversePilot capabilities. Any outreach still follows your organization's approval process.
Choose reverse mortgage LOS reference check questions by workflow
Start with a workflow your team needs to understand, rather than asking whether someone likes the software. “How did you handle a returned processing file?” can reveal who owned the next action. “Would you recommend it?” leaves the operating context unclear.
Use the LOS buyer guide and demo scorecard to identify unresolved evaluation questions. A reference's account can inform a follow-up test; it does not replace observing the proposed configuration yourself.
- Implementation: Which decisions did your staff supply before configuration could proceed? What work did you initially assume the vendor would own?
- Processing exceptions: Describe a returned file or replacement document. How did the receiving person identify the current version and next action?
- Coverage: When an assigned processor was unavailable, how did another person find and take responsibility for unfinished work?
- Adoption: Which tasks required extra training? What evidence showed users could finish the workflow without assistance?
- Support: Describe an unresolved issue. Who coordinated the response, and what information did your team supply?
Ask what happened in a specific example and what the speaker personally observed. Separate a current firsthand account from an expectation, an old experience, or something another department reported.
Establish what makes the reference comparable
Before interpreting an answer, record the speaker's role and the work they know directly. A technology sponsor may understand migration decisions but have limited visibility into day-to-day processing. Neither perspective is wrong; each answers different questions.
- Operating model and channels relevant to your evaluation.
- Roles using the workflow, including handoffs outside the platform.
- Configuration or version discussed, if known.
- Implementation stage and approximate period of the experience.
- Manual work, additional tools, or separately purchased services involved.
Ask only for information the participant is authorized and comfortable sharing. Avoid borrower records, account details, confidential agreements, and screenshots containing personal information. If an example needs detail, describe a synthetic file and ask about the process.
For background, the interagency Third-Party Risk Management guide for community banks discusses due diligence and third-party selection. It is a community-bank resource, not a mortgage-software reference script. The worksheet here is an editorial evaluation tool.
Copy a reusable reference question register
Keep the original question beside the answer and its limits. Do not compress a qualified answer into a positive or negative score before preserving its context. Record an evidence location only when you are authorized to retain the material.
| Blank field | What to capture |
|---|---|
| Workflow and question: ___ | The exact task and uncertainty from your demo. |
| Reference context: ___ | Role, operating model, experience period, and configuration if known. |
| Observed experience: ___ | Neutral paraphrase of what the speaker personally described. |
| Boundary or unknown: ___ | Different channel, manual step, unknown version, or missing firsthand knowledge. |
| Follow-up and owner: ___ | Evidence request or synthetic test, responsible role, and next checkpoint. |
For implementation questions, compare answers with your implementation responsibility worksheet. A reference's vendor-led experience does not establish which services another proposal includes. Keep proposed commercial scope with the procurement owner.
Work through a fictional unresolved answer
Imagine a fictional lender evaluating how replacement documents reach the receiving processor. An invented reference participant says the team always found the latest document, but also mentions a shared tracker outside the LOS. This is a teaching scenario, not a real customer account.
The useful conclusion is that the reference's process included another tool. Whether your proposed workflow can achieve the same result remains open. Preserve that boundary before turning the account into an evaluation decision.
A completed register might look like this:
| Field | Fictional completed entry |
|---|---|
| Question | After replacement, how does the receiving processor distinguish the current document from the prior version? |
| Context | Processing lead; retail workflow; exact software version unknown. |
| Experience | Team checked a separate shared tracker before reviewing the replacement. |
| Unknown | Whether the LOS alone preserved the review context and current-version signal. |
| Follow-up | Operations evaluator runs synthetic file REF-01 with the receiving role; vendor identifies every external dependency. |
In REF-01, create a synthetic document, record a review question, and replace it with a second synthetic version. Ask the receiving user to identify the current copy, the unresolved question, and the next owner. Record any manual tracker used. Carry the observed result into software acceptance testing.
Close evidence gaps without turning anecdotes into promises
When accounts differ, compare their boundaries before deciding that one is inaccurate. They may involve different roles, configurations, services, or periods. Ask the evaluator to identify which difference matters to the intended workflow.
- Preserve each account with its context and uncertainty.
- Translate the unresolved point into an observable scenario.
- Assign the evidence request or test to a named internal role.
- Record what remains unknown after the follow-up and how it affects the decision.
Do not treat a reference's experience as a support commitment, implementation timetable, or guarantee of future results. Confirm actual proposed terms through the appropriate commercial and legal review. A reference discussion informs the decision; it does not grant rights or approve rollout.
Key takeaways
- Ask about concrete workflows and firsthand experience.
- Record comparability limits and manual dependencies beside each answer.
- Turn unanswered questions into owned evidence requests or synthetic tests.
- Keep reference experience separate from proposed scope and acceptance.
Bring one unresolved workflow question to a ReversePilot evaluation conversation and ask what can be demonstrated in the proposed setup.