Define what the inbox owns
A recruiting inbox is a queue with several kinds of work mixed together. Applications, candidate replies, manager questions and vendor messages arrive together. A virtual assistant needs a written boundary before touching any of it. The boundary should say which messages the assistant answers, which it routes, and which wait for a named owner.
Start with a short inventory of message types from the last two weeks. Count how often each type appears and who currently answers it. The counts show where the assistant can remove the most repetition. They also show which rare but sensitive messages should never sit in the shared queue. A two-week window is long enough to show the pattern and short enough to remember the exceptions.
Write the boundary as a one-page table with four columns. List the message type, the first action, the owner and the response standard. Keep the language concrete enough that a new assistant can follow it without asking for context. Review the table with the recruiter who currently carries the inbox. Version the table with a date so the assistant can tell which rule was in force for an old message.
Separate triage from judgment
Triage is a set of repeatable decisions about where a message goes. Judgment is a decision about a candidate's fit, pay or eligibility. A virtual assistant can own triage quickly and should not own judgment without a clear approval route. Mixing the two creates either hesitation or unauthorized promises. Write the approval route beside the judgment call so the assistant knows exactly who decides.
Define the small number of judgment calls that must return to the recruiter. A rejected candidate who asks for feedback is one example. A hiring manager who asks to change a pay range is another. Put those examples beside the escalation contact so the assistant can recognize them under pressure. Review the list monthly because a new role can create a judgment call that did not exist before.
Give the assistant a default when the answer is unclear. The default can be to acknowledge the message, apply the correct label and route it to the named owner. A default prevents silence while protecting the recruiter from an uninformed reply. Test the default with three realistic messages before the live handoff. Record the default in the same place as the escalation route so the assistant does not rely on memory.
Write the response library and escalation routes
Most candidate questions repeat across roles and locations. Build short approved replies for scheduling, application status, document requests and interview preparation. Keep each reply specific to the step in the process instead of using one generic acknowledgment. The assistant should be able to paste, personalize and send without inventing policy. Retire replies that no longer match the current process and keep the old version for audit.
Pair every reply with a stop rule. A stop rule tells the assistant when the message has moved beyond the approved answer. For example, a request for a different interview time may need the scheduler, while a complaint about the interview process may need the recruiter. Write the stop rule in the same table as the reply. A stop rule that names the next owner removes the need for the assistant to guess.
Name a primary and a backup escalation contact for each shift. Include the channel, the expected response time and the phrase the assistant should use when escalating. An escalation that disappears into a personal inbox is worse than a visible queue item. The route should create a record that someone can audit later. Test the escalation route during a live shift, not only in the setup meeting.
Test access and identity before day one
Access problems create a false start that is hard to recover from. Confirm the assistant can open the applicant tracking system, the shared inbox and the scheduling tool before the first live shift. Check that the account name is correct and that the assistant can see the right locations and requisitions. Test a password reset while support is available. Keep a screenshot of the permissions page so a later access problem is easier to diagnose.
Identity matters when candidates receive a message from an unfamiliar name. Introduce the assistant in the first reply using a short, approved sentence. Explain that the assistant supports the recruiting team and name the recruiter who remains accountable. Candidates should never have to guess whether the message is legitimate. Use the same introduction in every channel so the candidate sees a consistent name and role.
Run a send test with an internal address before the assistant contacts a candidate. Confirm that signatures, reply-to addresses and time zone settings are correct. A small formatting error in a signature can make a routine message look like phishing. Fix the setup while the stakes are still low. Send the test to a colleague who will read it as a candidate would.
Review the first week with a sample
Do not wait for a complaint to review the handoff. Pull a sample of ten sent messages at the end of the first week. Check the label, the reply, the escalation and the time to first response. Read the candidate's follow-up as well, because a reply that looks complete can still leave a question unanswered. Choose the sample before reading the messages so the review is not shaped by a single complaint.
Score the sample against the written boundary rather than personal preference. Note every place where the assistant had to improvise. Those notes reveal missing instructions, not necessarily a performance problem. Update the table and the response library before the second week begins. Keep the notes anonymous when the review is shared beyond the immediate team.
Share two strong examples and two examples that need work with the assistant. Use the actual messages and remove candidate names. The review should teach the pattern, not only correct one message. End with one change the assistant will make in the next sample. Ask the assistant to explain the change in its own words before the next sample.
Keep a change log for the inbox
Recruiting processes change when a role opens, a hiring manager leaves or a new location starts. A change log records what changed, when it changed and who approved the new instruction. Without a log, the assistant learns from stale messages and the recruiter cannot explain a sudden shift in behavior. Review the log at the end of the month and remove entries that no longer affect the queue.
Keep the log next to the response library and review it in the weekly recruiting meeting. Add an owner and an effective date for each change. Mark old instructions as retired so the assistant does not apply two rules at once. A short log is enough when the entries are specific. Share the log with the backup so the weekly meeting is not the only place the change is known.
Use the new-hire question log and the payroll cutoff handoff as models for recording recurring questions and ownership. Both practices depend on the same discipline: one named owner, one written standard and one review date. Guidance on recordkeeping from the Department of Labor supports keeping the handoff instructions current and retrievable. A clean handoff gives the assistant room to work and gives the recruiter a way to check the result.