Mortgage support start-date readiness: check the dependencies

Before a mortgage support hire starts, confirm that the manager, approved systems, current instructions, practice work and first-week review time are ready. Give every dependency an owner and evidence of completion. A start date in a calendar does not establish that a person can begin the work assigned to them.

This pre-start checklist is for Australian brokerages hiring an assistant or loan processor, including a distributed team member. It covers operational readiness. Pair it with the first 30 days of processor onboarding for the learning plan after arrival.

Define a small first-week scope before arranging systems

Choose the first tasks the worker will observe, practise and return for review. That scope tells the manager which instructions, system setup and supervision must be ready. “Help with everything” makes it difficult to tell whether a dependency is essential for day one or can be completed later.

For a processor, the first scope might be checking a fictional document pack and recording missing items. For an assistant, it might be preparing appointment notes and a draft follow-up. Each task needs a clear input, expected output and named reviewer. Keep live-file allocation conditional on the readiness decision your team makes.

Confirm the scope against the processor hiring brief or your assistant brief. If the duties changed during selection, update the instructions before the worker sees conflicting versions.

Build a dependency register with evidence

Dependency	Owner	Completion evidence	Fallback
Manager and backup contact	Brokerage lead	Confirmed contact route and review times.	Named substitute reviewer.
Approved system setup	System administrator	Approved configuration checked with the worker.	Fictional offline practice.
Current instructions	Workflow owner	One current version and a successful walkthrough.	Manager-led demonstration.
Practice materials	Trainer	Fictional pack and an answer guide ready.	Another prepared simulation.
First review sessions	Named broker or lead	Calendar invitations accepted.	Adjusted first-week scope.
Work roster	Manager and worker	Local times and overlap confirmed.	Recorded handover arrangement.

Use “requested”, “in progress”, “verified” and “blocked” as separate states. Include the date and the person who verified completion. An invitation sent or a ticket closed may be useful evidence, but neither alone shows the worker can use the approved setup.

Check the full path the worker will use

Walk through the assigned workflow rather than testing isolated logins. Can the worker find the correct instruction, open the approved practice material, record an action and send the output to the reviewer? Can they identify a missing permission without improvising another route?

Use the task-based access matrix as a planning companion. Your authorised administrator should implement the permissions your brokerage approves. Keep credentials out of the readiness register; record the responsible administrator and verification result instead.

If a system depends on an external party, record that dependency separately. Confirm current access requirements through that party's actual process. Do not assume a colleague's account or a previous worker's configuration can be reused for the new person.

Work through a fictional blocked-start scenario

Imagine a processor is due to start on Monday. The manager and practice pack are ready, but an approved system setup is still pending. The broker has reserved two review sessions and was planning to allocate live preparation work on the first afternoon. This is an illustrative scenario, not a reported client experience.

The manager records the setup as blocked, names the administrator and asks for an update time. The worker begins with a fictional pack walkthrough and instruction practice. The broker reviews that output as planned. Live allocation waits for the missing dependency and the team's readiness decision; the queue remains with its current owner.

This response preserves useful learning while keeping ownership visible. If the delay extends, the manager changes the week's scope explicitly and tells the worker what will happen next. Do not leave them waiting without an owner, or quietly mark unperformed live tasks as started.

Agree who can make the readiness decision

Run a short readiness meeting before the planned start. Review only essential dependencies and unresolved blockers. The manager should know which tasks can proceed, which need another person and which are paused. Record the decision, the conditions attached and the next review date.

A task can be ready for observation but not ready for independent preparation. Use these distinctions in the register instead of one broad “onboarded” label. The first-week plan should say how completed practice work will be checked and how additional duties will be introduced.

Ask the worker to explain their contact route and next steps in their own words. This can expose mismatched time zones, obsolete instructions or unclear reviewer availability before those gaps affect an active file.

What if the manager will be away on day one?

Arrange a named substitute who can answer scope questions and review the planned practice output. Confirm that person has the current instructions and knows which work is approved for the first week. If no reviewer is available, reduce the starting scope to work that can safely wait for review under your team process. Record the changed plan with the worker before arrival so they do not receive a task list that depends on an absent manager.

Carry confirmed readiness into the first week

Keep the register short enough to maintain. Close verified dependencies, retain material decisions and move ongoing learning tasks into the onboarding plan. Review any blocker that remains open at the first management check-in. The aim is a usable starting point, not a large administrative checklist that nobody owns.

Use the loan processor hiring page or assistant hiring page to define the role, then compare relevant experience in the talent marketplace. Discuss your intended start date and dependencies so the hiring conversation reflects the work your team can actually support.