Google Apps Script vs When2meet for Recruiting Agency Panel Scheduling

Manual tutorial: run the panel process before buying software

Build the manual workflow once. It will show the real operating cost: not the cost of sending a poll, but the cost of keeping five calendars honest while a candidate is still warm.

Step 1: map every calendar that can block the interview

List the agency recruiter, coordinator, account lead, client hiring manager, client panelists, internal interviewers, external advisors, and the candidate. Note each system: Google Calendar, Outlook, shared mailbox calendar, personal Gmail, or a client-managed calendar. Mark which calendars are read-only, which can accept holds, and which domains will never grant access.

Step 2: define the panel rules by meeting type

Create a small matrix. Screen: recruiter plus candidate. Client intake: recruiter plus hiring manager. Technical panel: candidate, hiring manager, two panelists, and agency coordinator. Final: candidate, executive sponsor, recruiter, and account lead. This matrix tells you which calendars must be true before the agency offers a time.

Step 3: decide which facts may cross domains

For recruiting, the safest rule is strict: move only busy status, start time, end time, time zone, and a private source key. The destination hold should say Busy. Do not copy candidate names, client names, job titles, compensation notes, interview feedback, conference links, or email addresses into another corporate domain.

Step 4: create a masked Google Apps Script bridge

1. Create a destination calendar for each agency-side person who needs a cross-domain mirror. Name it Recruiting Busy Mirror.
2. Open Apps Script from the Google account that owns the mirror calendar.
3. Store source calendar IDs, destination calendar IDs, and allowed date windows in Script Properties rather than hard-coding them in the editor.
4. Read the next 30 days of source events and pull only start, end, status, updated timestamp, and event ID.
5. For each busy event, write a destination event titled Busy with the same start and end.
6. Store the source event ID in a private extended property so the next run updates the same hold instead of creating a duplicate.
7. Compare source IDs against mirror IDs on every run and delete mirror holds when the source event is canceled or removed.
8. Add a time-driven trigger every 5 minutes, plus failure email to a named coordinator or ops owner.

Step 5: add a When2meet poll only for calendars you cannot read

Use When2meet for the candidate, external panelists, or client users whose IT team will not permit calendar access. Keep the title neutral. Offer a narrow set of time windows. Do not put the client name, candidate name, role name, or confidential search details in the poll title or notes.

Step 6: place protective holds before the poll goes out

For every option shown in When2meet, place tentative holds on the calendars you control. If the agency offers six panel slots and protects none of them, the poll is collecting votes for inventory that can vanish while people respond.

Step 7: reconcile the winning slot within 15 minutes

When a slot wins, send the real invite, remove losing holds, update the ATS, and record which calendars were manually checked. A panel process that waits until end of day gives competitors a clean opening.

Step 8: audit the process every Friday

Check for duplicate Busy holds, canceled source events that still show in mirrors, polls with sensitive titles, stale tentative holds, failed script runs, and calendars that stopped syncing after an OAuth or admin policy change. If nobody performs this audit, the process will drift.

Where the manual bridge and poll process breaks

The first panel often works because everyone is watching it. The tenth panel breaks because recruiters are juggling intake calls, submittals, candidate prep, reference checks, and offer timing. The failure mode is not dramatic. It is a slow pileup of stale slots and quiet rework.

Latency creates false confidence

A 5-minute Apps Script trigger sounds fast until a client books a meeting, the script waits for the next run, the booking tool reads cached availability, and the candidate picks the same slot. With When2meet, latency is even more direct: the process waits on humans. One executive who answers the poll tomorrow can delay the panel by a full business day.

Caching hides the miss

Calendar APIs, booking pages, browser sessions, and polling pages may not show the newest state at the same moment. The recruiter can refresh one screen and think the slot is safe while another participant sees older availability. That is how two people can be right and the process can still fail.

Double bookings punish the agency brand

Double bookings are not just calendar defects. They tell the client the agency does not have control of the process. They tell the candidate the opportunity may be disorganized. For retained search, executive hiring, and competitive technical roles, that trust loss matters.

Data privacy exposure compounds across participants

Recruiting calendars carry sensitive context: replacement searches, confidential backfills, compensation discussions, candidate feedback, immigration topics, client account names, and interview links. A rushed script that copies the full event body can move that context into the wrong tenant. A casual poll title can expose the search to anyone with the URL.

Admin firewalls appear late

The client may block external calendar apps. Google Workspace may block Apps Script scopes. Microsoft 365 may restrict external sharing or unknown polling links. Security teams can be right to block these paths, but the agency still needs to schedule the panel this week.

3-way B2B comparison: Apps Script bridge vs When2meet poll vs WonderCal

Do not compare these tools by asking which one can help book a meeting once. Compare them by operating vector: how fast the truth moves, whether updates flow both ways, what private data crosses domains, how much admin friction appears, and how the cost scales across the recruiting team.