# Interviewer availability and slot scheduling UX for research interview tools Market Research Report - Global

**Generated on:** 2026-10-20 09:04:49.017434  
**Industry:** Interviewer availability and slot scheduling UX for research interview tools  
**Geography:** Global  
**Details:** # Deep research prompt: interviewer availability and slot scheduling for a live-interview research tool

## Your role
You are a senior UX researcher and product strategist. Produce an evidence-based report that a product designer and a developer can act on directly. Prioritise official vendor help documentation, published usability research and platform API documentation over blogs and marketing pages. Where you cannot verify something, say so plainly rather than guessing.

## Rules for evidence (read before starting)
- Every exact UI label you quote must come from a source you can link to (help doc, changelog, screenshot in official docs). Put labels in quotation marks and add the source link and the date of the page or article.
- If you cannot verify a label, write "label not verified" and describe the pattern instead. Do not invent wording.
- Vendor UIs change often. Flag anything from sources older than 18 months as "may be out of date".
- Separate three kinds of evidence and label each claim: **[Documented]** (vendor docs), **[Research]** (published usability study, academic paper, NN/g, Baymard or similar), **[Inferred]** (your reasoning).
- Note where tools disagree with each other and why that might be.
- Use UK English.

## Context
Voxpopme is a video-based qualitative research platform. Its product **Sessions** runs live 1:1 video interviews between a company's staff (**interviewers**, for example researchers or marketers running a "consumer connect" programme) and recruited consumers (**participants**). Interviews run inside the platform with a discussion guide on screen.

### How scheduling works today
1. A **project admin** creates a project and a **recruit round** (a batch of participants), then adds interviewers by invite or by sharing a sign-up link with a whole department.
2. Each interviewer opens the scheduler and **adds availability** for the study's interview length (usually 15 or 30 minutes). They click individual slots on a calendar grid. There is a setting for how many interviews they will do, an option labelled **"Grouped"**, and a **"gap between interviews"** setting. They can **import a calendar file** (.ics export) to grey out busy times. There is **no live calendar connection**.
3. The admin sees a project-level view of all open slots across interviewers and decides whether to launch recruitment or ask for more availability.
4. Participants are screened, record an audition video, get approved, then pick **one** slot from pooled availability and receive a confirmation email and calendar invite.

### Users and constraints
- Interviewers are busy staff at large enterprise clients, often on Microsoft 365/Outlook, sometimes in locked-down tenants that need IT admin consent for third-party apps. Some are Voxpopme's own researchers.
- Interviewers often run several studies at once and their calendars change constantly.
- Participants are consumers worldwide, so time zones matter.
- Some interviewers do not want the tool to block their real calendar. They prefer to offer a wide window and move their own meetings if someone books.
- Product leadership leans towards "buy not build": Cal.com's embeddable booker / Platform API ("atoms"), or a Microsoft Graph integration for live free/busy.

### Evidence from an internal test
12 staff were asked to add availability for a 15-minute interview across three days. About a third completed it. One experienced researcher recorded a walkthrough. Six problems emerged:
1. **No range selection.** Wanted "available 9 to 5" in one action; each slot had to be clicked individually.
2. **Can't fit several short interviews per hour.** 15-minute interviews should allow four per hour, 30-minute two.
3. **"Grouped" label unclear.**
4. **Gap between interviews setting didn't visibly change anything.**
5. **Calendar file import felt unfamiliar** and can't stay current across concurrent projects.
6. **Day targets too small** to click into individual days.

Other feedback: interviewers want to see availability they have already added (including earlier dates and other projects; one was "100% sure" she had added more). The calendar looked busy with one person, raising concerns about scale. An earlier multi-date select design failed because users didn't realise multi-select existed.

Note the limits of this evidence: small internal sample, staff rather than client users, one recorded walkthrough. Treat it as signals, not proof, and say where external evidence supports or contradicts it.

## Tools to compare
- **General scheduling:** Calendly, Cal.com (including Platform / embed atoms), SavvyCal, Microsoft Bookings, Google Calendar appointment schedules, Zoom Scheduler, Doodle.
- **Research-specific:** User Interviews, Respondent, Great Question, dscout, Lookback.
- **Include if relevant:** Rally, Ethnio, UserTesting, Askable.
- Add any other tool you find that handles pooled moderator availability particularly well, and say why you included it.

## Research sections
Answer each section with patterns, default values, exact UI labels (verified), and evidence on what works.

### 1. Setting an availability window
- Weekly recurring hours versus date-specific overrides: how each tool handles both, and the labels used.
- Interaction patterns: drag-to-paint on a grid, start/end range inputs ("9:00 to 17:00"), click-per-slot. Evidence on speed and error rates for each.
- Copying hours to other days and bulk editing across several days. Exact controls and labels.
- How tools make multi-select discoverable, given that a previous multi-date design failed for Voxpopme.
- Target sizes for day cells and slots; relevant guidance (for example WCAG 2.2 target size, Fitts's law research).
- How availability for a **specific study or date range** differs from general working hours.

### 2. Turning a window into bookable slots
- How tools split a range into slots (four 15-minute or two 30-minute per hour).
- Meeting length versus start-time interval (for example "start times every 15 minutes"). Defaults and labels.
- Whether and how the resulting slots are previewed back to the person setting availability.

### 3. Gaps, buffers and limits
- Buffer before and after, minimum notice, daily and weekly caps. Defaults and labels.
- Do buffers apply only around booked meetings, or between every slot? How each tool explains this.
- How buffers and caps are previewed so the effect is visible.
- Known confusion and labels that test well. Specifically: what would be clearer than "Grouped" (find out what equivalent features are called elsewhere, for example back-to-back booking, consolidating meetings, "front-loading").

### 4. Calendar import and sync
- One-off .ics upload versus subscribed ICS URL versus OAuth free/busy (Google, Microsoft 365 via Graph, Apple/CalDAV). Pros, cons, freshness.
- Checking several calendars for conflicts; writing bookings back.
- Patterns for **not** blocking the whole window (soft availability, "check for conflicts" toggles, tentative holds).
- Enterprise IT admin consent: what scopes Graph free/busy needs, whether user consent is enough, how tools handle tenants that block third-party apps, and fallback flows.
- What research-recruitment tools do for moderators who never connect a calendar.

### 5. Pooled and multi-interviewer scheduling
- Round-robin, collective and "any available moderator" patterns. Labels and defaults.
- Per-study versus per-person availability.
- Assignment rules (load balancing, priority, maximum per interviewer).
- Admin views of total capacity at scale. How tools visualise many interviewers without clutter.

### 6. Seeing and reusing past availability
- Named schedules and templates (for example "Working hours", custom schedules per event type).
- Duplicating last week's availability; carrying availability across studies.
- Showing existing commitments across projects so people trust what they have added.

### 7. Time zones
- How tools detect, display and let people change time zones for both sides.
- Handling interviewers and participants in different zones, daylight saving changes, and dates that shift across midnight.
- Known failure modes and how they are mitigated.

### 8. Prompts and nudges
- How tools get busy stakeholders to add availability fast, ideally under a minute: email deep links, "share your usual hours", calendar connect on first use, one-tap defaults.
- Reminder cadence and escalation to admins when capacity is low.
- Any published data on completion rates.

### 9. Participant-side impact
- How interviewer-side choices (slot density, buffers, notice, time zones) affect participant booking rates and no-shows.
- Evidence on how many slots participants need to see for good conversion.

### 10. Build versus embed versus integrate
- Compare three options: build in-house, embed Cal.com Platform / atoms, integrate Microsoft Graph directly.
- For each: what it solves among the six problems, what it doesn't, cost and licensing, white-labelling, control over the UX, data residency, maintenance burden, and lock-in.
- Is Graph alone enough, given some clients use Google Workspace and some interviewers won't connect anything?

### 11. Privacy and security
- Risks of exposing interviewers' schedules to admins, other interviewers or participants.
- What free/busy versus full event detail reveals; what tools show by default.
- GDPR considerations for enterprise clients and global participants.

### 12. Edge cases and failure modes
- Double-booking across concurrent studies, last-minute calendar changes, cancellations and reschedules, interviewer drops out of a pool, availability added after recruitment launches, interviews longer than slot grid.
- How established tools handle each.

## Output required
1. **Comparison table**: tools as rows, sections 1 to 8 as columns, with specific patterns and verified wording. Mark unverified cells clearly.
2. **Top 5 to 8 design recommendations** for the Voxpopme scheduler. Tie each to one or more of the six problems above, state the evidence level, and give specific values (for example default buffer, default interval) rather than ranges.
3. **Label suggestions** for "Grouped" and "gap between interviews": a recommended label plus two alternatives each, with helper text and evidence. Labels must work in both US and UK English.
4. **Risks and trade-offs** for build versus Cal.com embed versus Microsoft Graph, including enterprise consent and schedule privacy.
5. **What the evidence does not support**: assumptions in this brief that look weak or wrong, and anything the team may be overlooking.
6. **Open questions** to test with real client interviewers.
7. **Sources**: full list with links and publication or last-updated dates, grouped by type (vendor docs, usability research, API docs, other).

Be concise but complete. Flag anything surprising.

---

# Faster, Safer Interview Scheduling for Voxpopme Sessions

## Executive Summary

- **Fix Authoring Before Integration**: **[Research - internal signal]** About one third of 12 staff completed the supplied task; this is a warning, not a client completion-rate estimate. **[Inferred]** Replace individual-slot clicking with explicit time ranges, visible day selection and an immediate booking preview before introducing calendar permissions.
- **Separate Duration From Cadence**: **[Documented]** Calendly separates start-time increments from meeting settings; Doodle defaults its booking interval to the event duration. **[Inferred]** Default Voxpopme's interval to the interview duration: **15 minutes for a 15-minute interview; 30 minutes for a 30-minute interview**. [6][8]
- **Resolve The Meaning Of Gaps**: **[Documented]** dscout spaces generated slots; Calendly checks buffers around meetings. These are different scheduling models. **[Inferred]** Decide which Sessions intends before renaming its existing control. [52][3]
- **Do Not Procure Deprecated Atoms**: **[Documented]** Cal.com's Platform/Atoms documentation says it is deprecated, maintained for existing users and **closed to new Platform customers**. **[Inferred]** Evaluate its current hosted embed/API offer separately; do not base the roadmap on the old Platform proposition. [2][26]
- **Treat Consent As A Product State**: **[Documented]** Delegated Graph `Calendars.ReadBasic` does not intrinsically require admin consent, but tenant policies can prevent users consenting. **[Inferred]** Offer an administrator-approval path and a fully functional manual fallback. [18][39]
- **Show Capacity, Not Calendar Noise**: **[Documented]** Great Question offers availability-first and fairness-first moderator distribution; Cal.com forms pooled availability from hosts' union of slots. **[Inferred]** Show achievable interviews and coverage gaps, not a pile of overlapping interviewer calendars. [14][7]
- **Reject Unsupported Conversion Promises**: **[Research]** Healthcare evidence shows online scheduling associated with lower no-shows in one setting and higher no-shows in another. **[Inferred]** Do not promise that denser slots, calendar connection or a particular number of choices will improve research-interview attendance without testing. [29]

**Scope:** Global; reviewed **20 October 2026**. This is a product/category assessment, not a market-size estimate. No defensible revenue, market-share or adoption ranking for this narrow UX category was established.

**Evidence key:** **[Documented]** = official vendor documentation, API reference or explicitly identified vendor claim; **[Research]** = published research/guidance, with the supplied internal study identified separately; **[Inferred]** = recommendation or interpretation. Proposed copy is not a verified vendor label.

**Dates and labels:** Quoted vendor wording is linked through the adjacent citation and the dated source register below. **U = not verified; label not verified**, not proof that a feature is absent. Undated sources have unknown freshness. Sources before **20 April 2025** are marked **may be out of date**, including older UI documentation.

## 1. Competitive Patterns Across The Eight Scheduling Tasks

**[Documented]** The useful competitive divide is between reusable personal scheduling, study-level recruitment scheduling, and calendar infrastructure. The table records verified capabilities, not comparative usability or plan entitlement. Source codes identify the full links and dates in References.

| Tool and dated sources | 1. Window authoring | 2. Slot generation / preview | 3. Gaps / limits | 4. Calendar connection | 5. Pools / assignment | 6. Reuse / history | 7. Time zones | 8. Prompts / nudges |
|---|---|---|---|---|---|---|---|---|
| **Calendly** - V1-V3, 20 Aug 2026; V4, 5 Oct 2026 | "Weekly hours"; "Date-specific hours"; start/end blocks; select or drag across dates; "Edit all [day of the week]". [5] | "Start time increments"; check booking page after editing; default increment U. [6] | "Limits and buffers"; before/after; notice and booking limits. [3][6] | Connected-calendar conflict checks; optional buffer display on connected calendar. [3] | "Maximize for availability" versus "Optimize for equal distribution"; priorities. [59] | Named schedules; reuse across event types; "Copy from". Past cross-project view U. [5] | Host/invitee detection; location-zone locking option. [6] | Availability-request cadence and completion data U. |
| **Cal.com** - V5-V10, undated; A1-A2, undated | "Working hours"; initially Mon-Fri 09:00-17:00; "Copy times to", "Select all", "Apply"; "Add an override". [55] | Availability troubleshooting explains blocked times; interval/default U in reviewed help. [51] | User-wide daily/weekly/monthly/yearly caps; "Limit booking frequency". [42] | Multiple conflict calendars; per-link overrides; separate destination calendar. [57][56] | "Round Robin"; union of hosts; priorities, weights, least-recently-booked. [7] | Multiple named schedules; "Set as default"; legacy Atoms delete expired overrides. [55][2] | "Timezone" per schedule; troubleshooting zone selector. [55][51] | Email invitation onboarding; availability-completion metrics U. [56] |
| **SavvyCal** - V11, 7 Aug 2025; V12-V14 older* | Weekly ranges or calendar-event-defined blocks; bulk/date override controls U. [11] | "Start Time Increments"; "Preview"; invitee calendar overlay. [49][11] | "Buffer Before", "Buffer After", "Minimum Notice"; global/per-link frequency caps. [49][50] | Calendar overlay documented; precise provider/permission controls U here. [11] | One-to-one/collective, round-robin, group link types. [11] | Global defaults versus per-link settings; named study-template/history flow U. [49][50] | Detailed detection/DST controls U. | "Highlight preferred times"; "Batch meetings together" guides bookers, not interviewer completion. [10] |
| **Microsoft Bookings** - V15-V17, 2-10 Apr 2025* | "Use business hours" or daily start/end dropdowns; additional blocks; days off. [40] | Time increments configurable from 5 minutes to 4 hours; default U. [20] | Lead/cancellation time and booking horizon; reviewed buffer/cap defaults U. [20] | "Events on Microsoft 365 calendar affect availability" on by default; external-tenant staff cannot share free/busy. [46] | Staff-based services; round-robin/fairness rules U in reviewed sources. | Business-hours baseline and staff-specific hours; past cross-study history U. [40] | Detailed customer-zone control U. | Staff booking/change emails; availability-chasing cadence U. [46][20] |
| **Google Calendar appointment schedules** - V18, undated | "General availability", "Adjusted availability", "Copy time to all". [9] | "Appointment duration"; separate start-interval/default U. [9] | "Buffer time", "Maximum bookings per day"; default minimum lead time **4 hours**. [9] | "Check calendars for availability"; co-host calendars **not checked by default**. [9] | "Co-hosts" is not evidence of automatic round-robin assignment. [9] | Reusable appointment schedule; cross-study ledger U. | Zone set with availability. [9] | Confirmation/reminders; up to **5 reminders**; text not editable. [9] |
| **Zoom Scheduler** - V19, undated | Daily ranges; multiple blocks; copy icon then "Apply" / "Apply to all"; "Exclude specific dates". [24] | "Duration" versus "Show schedules in increments of". [24] | "Buffer time between schedules"; before/after; daily attendee limit. [24] | Invalid host calendar connection can make rotating schedule unbookable. [24] | "Any Host Available"; "Prioritize fairness" / "Prioritize availability". [24] | "Repeats": "Forever" / "Date Range"; historical reuse U. [24] | Profile zone default; booker can change location zone. [24] | Calendar invitation/email confirmation; availability-chasing evidence U. [24] |
| **Doodle Booking Page** - V20, 11 Nov 2024*; V21, updated 28 Sep 2026 | Booking-page duration configurable; detailed weekly copy/override controls U here. [54] | "Booking Interval" defaults to "Same as event duration". [8] | "Buffer Time" defaults to "No buffer time"; after-event spacing. [8] | Linked calendar prevents conflicts; reschedules update calendar. [54] | Booking Page is not evidence of pooled moderator assignment; U. | Reusable booking page; cross-study view U. | Invites adapt to attendees' zones; author can offer availability in different zones. [54] | Booking reminders; interviewer availability completion U. [54] |
| **User Interviews** - V22, 13 Jul 2026 | Project calendar and session editor; range/drag/copy controls U. [13] | Session scheduling and focus-group capacities; separate start cadence U. [13] | Buffer/notice/default caps U in this source. | Google/Outlook availability plus confirmed-session write-back; collaborator calendar connection. [13] | Collaborators documented; automated moderator rotation U. [13] | Project calendar; cross-project history/reuse U. | Study zone configured during draft; participants see conversion from profile location. [13] | Calendar-connection prompt documented; reminder/completion cadence U. [13] |
| **Respondent** - V23, 21 Apr 2025 | "Day of the Week Availability Settings" defaults individual days to **09:00-17:00**; "Interval" means the availability window. [12] | "Length of Interview" versus "Increments"; preview/default cadence U. [12] | "Minimum Scheduling Notice"; "Buffer Before Booking" documented for Google integration only; after buffer also available. [12] | Google-linked before-buffer behaviour documented; full current provider/fallback matrix U. [12] | Pooling/assignment U. | Cross-study reuse/history U in this source. | Default window uses calendar zone; detection/change controls U. [12] | Availability-request reminders/completion U. |
| **Great Question** - V24, undated | Study dates/hours; all selected weekdays currently share one start/end time. [14] | Duration in 15-minute increments; "Participant preview". [14] | Buffers, notice, daily/weekly limits; caps apply to **study**, not each moderator. [14] | Google Workspace or Microsoft, one provider at a time; moderators' connected calendars supply availability. [14] | "Standard 1:1", "Collective", "Round Robin"; "Availability" / "Fairness". [14] | Calendar-backed per-study configuration; historical reuse U. | Study zone plus participant preview. [14] | Participant invitation link; stakeholder availability nudges U. [14] |
| **dscout** - V25-V27, undated | Bulk generator with days/time ranges; manual slot creation. [52] | Generate slots; inspect/edit calendar; breaks **0 minutes to 1 hour**. [52] | Break inserted between generated slots; other cap/notice defaults U. [52] | Manual authoring documented; live conflict checking U in these sources. [52] | Assign moderator during generation or later; up to two moderators per slot. [52][48] | Edit after launch; newly added slots require publishing. Cross-study carry-over U. [52] | Detailed detection/change behaviour U. | Participant confirmation; suggested message 5 minutes before session, not an availability-request automation. [48] |
| **Lookback** - V28, undated; vendor feature claim | Native moderator availability controls U. | Automated scheduling claimed for recruitment powered by User Interviews. [16] | U | U | Native moderator pool assignment U. | U | U | Native availability-request workflow U. |
| **Rally** - V29, undated marketing; V30, 26 Jul 2023* | Changelog describes "Set Personal Availability"; current detailed authoring controls U. [32] | Configurable start-time increment in older changelog; default U. [32] | Marketing describes conflicts, buffers and rescheduling; exact current controls U. [28] | Calendar connection documented as a pattern; detailed current provider/scopes U. [28] | Vendor describes 1:1, collective and round-robin. [28] | Personal availability; study-template/history behaviour U. | U | Automatic participant reminders claimed; stakeholder completion U. [28] |
| **Ethnio** - V31, 17 Jul 2026; V32, 17 Jun 2025 | Click calendar to create interview spots; bulk range controls U. [34] | Researcher-created spots; participants express scheduling choices. [34] | Number of participant time choices configurable; buffer defaults U. [33] | Conflict checking/Outlook integration listed; detailed permissions/freshness U. [34] | Up to **6 facilitators** on a study; this does not establish round-robin allocation. [34] | Study schedule; cross-study reuse/history U. | Participants must choose zone; vendor calculates difference. [34] | Invite then confirm; configurable email/text reminders. [34] |
| **UserTesting** - V33, 24 Jun 2026 | Moderator sets availability in Live Conversation scheduler; exact authoring controls U. [36] | Slot-generation controls/defaults U. | U | Google and Outlook calendar visibility in scheduler. [36] | U | U | U | U |
| **Askable** - V34, relative update only | Session-slot management; authoring interaction U. [19] | "Calendar" shows session slots. [19] | U | U | Moderator allocation U. | Study participant/calendar views; cross-study reuse U. | U | Progress summary includes booked sessions, remaining quota and study days; automatic capacity nudges U. [19] |

* **May be out of date:** SavvyCal introduction, buffer and frequency-limit pages; Bookings pages; Doodle interval/buffer page; Rally's 2023 changelog. Other, newer pages for those vendors should not be mistaken for updates to these specific controls.

**[Inferred] Decision:** Use Calendly/Cal.com for authoring and diagnostic patterns, Great Question for research-specific pool policy, and dscout for bulk study-slot creation. Do not infer a native moderator scheduler from recruitment or video-interview marketing alone.

## 2. Author Windows Once, Then Explain Every Bookable Slot

### Range inputs should be primary; dragging should be optional

**[Documented]** Calendly supports start/end blocks, date-specific editing and dragging across dates. Cal.com exposes explicit copying to selected days. dscout offers bulk generation as well as individual slots. These are capability precedents, not evidence that any interaction is fastest. [5][55][52]

**[Research]** NN/g recommends calendars for date ranges and direct entry where navigation is cumbersome. Its date-input article is dated **22 January 2017: may be out of date**. Fitts's law, reviewed by MacKenzie in **1992**, explains target-acquisition performance but does not establish a speed/error advantage for a scheduling interaction. No direct, applicable comparative study of drag-to-paint, typed ranges and click-per-slot was established here. [25][30]

**[Inferred]** Make the first-use path: selected study dates -> visible day checkboxes -> one start/end range -> explicit application to those days -> preview -> save. Show the selected-day count and resulting dates continuously. Offer dragging as an accelerator, never as the only discoverable bulk action. Do not silently apply a recurring weekly template outside the recruit round.

**[Research]** WCAG 2.2 requires **24 x 24 CSS-pixel** pointer targets or an applicable exception; this is not a recommendation to make dense calendars exactly that small. Drag functionality also needs a non-drag single-pointer alternative. **[Inferred]** Use **44 x 44 CSS-pixel** day controls where possible, visible focus/selection, keyboard operation and list-based editing. Test these sizes rather than claiming 44 pixels is WCAG's AA minimum. [1][43]

### Slot maths must distinguish choices from capacity

**[Inferred - computed examples]** A candidate start must fit the complete interview inside its window. Changing the start interval changes the choices offered; it does not create more moderator time. For one interviewer available **09:00-10:00**, with a gap required only between booked interviews:

| Interview duration | Start interval | Required gap | Candidate starts before bookings | Maximum mutually compatible interviews |
|---|---:|---:|---:|---:|
| 15 minutes | 15 minutes | 0 minutes | 4 | 4 |
| 30 minutes | 15 minutes | 0 minutes | 3 | 2 |
| 15 minutes | 15 minutes | 5 minutes | 4 | 2 |
| 15 minutes | 20 minutes | 5 minutes | 3 | 3 |

**[Inferred]** The third row is a hidden product trap: a five-minute gap combined with a quarter-hour grid can halve achievable capacity. Preview both candidate choices and achievable interviews, not just a slot count.

### Case study: dscout's generated slots versus Calendly's dynamic buffers

**[Documented]** dscout generates slots from an availability window and places a configurable break between those generated slots. Moderators can be assigned during generation; otherwise they must be assigned later. Newly added slots after launch require publication before participants see them. The documented outcome is a visible, deliberately authored interview schedule. [52]

**[Documented]** Calendly instead checks whether meetings and their buffers fit around calendar conflicts. Its buffers may extend outside working-hour boundaries, and before/after buffers can stack between meetings. Its current "Include buffers on this calendar" control can make protection visible externally; that label is from **20 August 2026**, V3. [3]

**[Inferred]** This explains why changing a gap can appear ineffective: a booking-relative buffer need not remove every alternative start before anyone books. Voxpopme should show an example booked interview, its protected gap and the resulting next start. Show the same rule in the participant preview and admin capacity calculation.

### Proposed replacement copy - not verified vendor wording

**[Inferred]** First confirm what the existing grouping setting actually does. The following are untested proposals, not labels known to test well.

| Existing control | Recommended proposed label | Two alternative proposed labels | Proposed helper text | Evidence and conditions |
|---|---|---|---|---|
| Grouping setting | **Prefer back-to-back interviews** | **Keep interviews together**; **Minimise gaps between interviews** | Prioritise times next to interviews already booked. Other available times remain bookable. | Only appropriate for a soft clustering preference. SavvyCal's verified "Batch meetings together", **7 Aug 2025**, encourages bookings close to existing events. [10] |
| Gap setting | **Break after each interview** | **Time between interviews**; **Post-interview buffer** | After an interview is booked, keep 5 minutes free before another interview can start. | Change 5 to the chosen value. Calendly protects booked meetings; dscout instead spaces generated slots. The wording must match the implementation. [3][52] |

**[Inferred]** If grouping forces consecutive appointments, remove the word *Prefer* and explain the restriction. If it means earliest-first or front-loading, none of the grouping proposals is accurate: use **Offer earlier times first** and explain which later times disappear. If the gap is baked into generated slots, say **Space interview slots apart** instead of describing booking-relative protection.

**[Inferred] Decision:** Ship range authoring, explicit bulk selection and a truthful preview as one change. A label-only fix will not solve an invisible or inconsistent scheduling rule.

## 3. Calendar Connectivity, Consent And Schedule Privacy

### Connectivity methods solve different problems

| Method | Freshness and conflict value | Booking write-back | Main trade-off |
|---|---|---|---|
| **One-off .ics upload** | **[Documented]** Snapshot; no automatic updates. [22] | **[Inferred]** A separate invite/write mechanism is needed. | **[Inferred]** Useful fallback, unreliable as continuing conflict protection; may import unnecessary event details. |
| **Subscribed ICS URL** | **[Documented]** Outlook refresh is asynchronous: approximately every 3 hours, sometimes over 24 hours. This is Outlook-specific, not a universal ICS SLA. [22] | **[Inferred]** Subscription does not itself establish bidirectional booking management. | **[Inferred]** Better than a snapshot, insufficient as the only final conflict check. Treat subscription URLs as secrets. |
| **Google/Microsoft authorised API connection** | **[Documented]** APIs can query current free/busy. [4][21] | **[Inferred]** Booking creation requires a separate write operation and appropriate permission. | **[Inferred]** Best conflict-checking foundation, but still subject to token expiry, outages, tenant policy and booking races. |
| **Apple/CalDAV connector** | **[Inferred]** Requires provider-specific implementation and credential handling; it is not a Microsoft Graph extension. | Provider-specific. | Apple/CalDAV authorisation, supported methods and freshness were **not verified** in the reviewed primary documentation; require confirmation before promising support. |

**[Documented]** Cal.com separates calendars checked for conflicts from the destination calendar receiving bookings. Its per-link conflict rules do not remove the cross-link protection provided by its own bookings. Microsoft Bookings also allows calendar conflict checking to be configured independently of staff working hours. [56][57][46]

**[Inferred]** Keep three concepts separate in Sessions: offering a window, checking external conflicts, and writing a confirmed interview. Offering **09:00-17:00** should not create an eight-hour hold. Write only actual bookings by default. An interviewer who wants to ignore external conflicts should explicitly choose that behaviour; Voxpopme's own confirmed interviews must still prevent double-booking across studies.

### Microsoft consent: minimum scope does not mean guaranteed access

**[Documented]** The current Graph `getSchedule` reference, updated **23 July 2025**, lists `Calendars.ReadBasic` as least-privileged delegated work/school access. Personal Microsoft accounts are unsupported by this operation. The permissions reference shows delegated `Calendars.ReadBasic` with admin consent **No**, while application `Calendars.ReadBasic.All` requires admin consent **Yes**. [4][18]

**[Documented]** Entra administrators can disable user consent or limit it to approved publishers/permissions. The admin-consent workflow lets blocked users request approval, emails designated reviewers and notifies the requester. It must be enabled; it is not a universal automatic fallback. [39][44]

**[Inferred]** Build explicit states for connected, approval required, pending approval, declined, expired and disconnected. Preserve manually added availability throughout. Give IT a permission-purpose explanation and app details; give the interviewer a route back to scheduling without waiting for IT.

**[Documented]** A Microsoft conceptual guide last updated **7 November 2024 - may be out of date** says `Calendars.Read`, whereas the newer endpoint reference allows `Calendars.ReadBasic`. Follow the newer operation-specific reference. Also, Graph's default **30-minute** `availabilityViewInterval` describes the returned availability view, not an interview start interval. [45][4]

### Privacy case: free/busy access is not the same as harmless data

**[Documented]** `Calendars.ReadBasic` excludes bodies, attachments and extensions, but permits basic event reading: it is not an OAuth scope restricted exclusively to busy blocks. Microsoft's older free/busy guide also describes conditional subject/location disclosure depending on calendar access. Google free/busy responses provide busy ranges rather than event descriptions. [18][45][21]

**[Inferred]** Normalise connector responses to busy intervals and discard titles, locations, attendees and descriptions before they reach project admins or analytics. Interviewers see their own windows and bookings; admins see study capacity, assignment and connection health; other interviewers see only necessary coordination; participants see bookable choices and their assigned interviewer, not raw schedules.

**[Research]** ICO principles require minimisation, transparency, storage limitation, security and accountability. **[Inferred]** Apply these through documented controller/processor roles, appropriate lawful basis, a DPA/subprocessor review, retention/deletion rules, token encryption and revocation, role-based access and lawful international-transfer arrangements. OAuth consent is not, by itself, the GDPR lawful basis for every downstream use. [53]

**[Inferred] Decision:** Add Microsoft and Google conflict connectors behind a provider-neutral interface, while retaining manual study windows. Do not make calendar authorisation a prerequisite for participation in an enterprise research programme.

## 4. Pools, Reuse, Time Zones And Capacity Nudges

### Pooling is a policy choice, not one feature

| Model | Availability mechanism | Benefit | Trade-off for Sessions |
|---|---|---|---|
| Any available interviewer | **[Documented]** Union of eligible hosts' slots. [7] | **[Inferred]** Broadest participant choice. | **[Inferred]** Workload can skew towards the most available people. |
| Fairness-oriented round-robin | **[Documented]** Calendly can hide a host's availability when three or more meetings ahead; Zoom and Great Question offer fairness modes. [59][24][14] | **[Inferred]** More even workload. | **[Inferred]** May withhold genuinely available times and reduce coverage. |
| Collective interview | **[Documented]** Great Question requires multiple moderators together. [14] | **[Inferred]** Supports co-moderation. | **[Inferred]** Needs the intersection, not union, of required hosts' availability. |

### Case study: availability-first versus fairness-first

**[Documented]** Great Question makes this trade-off explicit through "Availability" and "Fairness" within "Round Robin" scheduling; its page is **undated**, V24. Its daily and weekly limits apply to the study overall, not individually to each moderator. That scope matters when a participant pool spans researchers with different workloads. [14]

**[Documented]** Cal.com offers priorities, weights and least-recently-booked allocation, while Calendly's equal-distribution counts reset when hosts are added or removed. These mechanisms can produce different assignments from the same free time. Neither the word round-robin nor an apparent equal-weight setting guarantees equal eventual workload. [7][59]

**[Inferred]** Default Sessions to availability-first, then choose the least-loaded eligible interviewer within explicit personal caps. Keep study caps and cross-study personal caps separate. Admins should see one row per interviewer with committed quota, feasible remaining interviews, bookings, date coverage and connection status; expand into a calendar only on demand.

**[Inferred]** Capacity must avoid counting the same person's overlapping windows across studies twice. Maintain a single interviewer-level booking ledger, with study offers layered above it. For fixed assignments, calculate non-overlapping intervals; for shared candidate starts, calculate feasible assignments rather than summing every displayed start time. Report approved-but-unbooked participants and coverage by participant-local day/time alongside total capacity.

### Reuse should preserve provenance

**[Documented]** Calendly reuses schedules across event types, while Cal.com supports multiple schedules and a default schedule. Legacy Cal.com Atoms delete date overrides after their dates pass. None of these facts establishes an adequate history view for Voxpopme's users. [5][55][2]

**[Inferred]** Offer an explicit copy of the previous study/week into this recruit round, followed by review. Retain a read-only history of what was offered, changed and booked, including past dates and source project. Distinguish offered availability, external busy time and confirmed research interviews; do not make users reconstruct history from today's calendar.

### Global time zones need more than automatic detection

**[Documented]** Calendly detects host/invitee zones; Zoom defaults to the profile zone but lets bookers change it; User Interviews converts from participant profile location; Ethnio asks participants to choose their zone. These different starting assumptions can disagree for travellers or stale profiles. [6][24][13][34]

**[Inferred]** Display the named zone next to every editor and booking view, permit correction, and show the full participant-local date in confirmation. Store recurring hours with an IANA zone; store confirmed appointments as instants plus display-zone context. Test nonexistent and repeated daylight-saving times, different countries changing clocks on different dates, and interviews crossing midnight. Changing an account zone must not silently move a confirmed interview.

**[Inferred]** Nudge through a study-specific email deep link with duration, deadline and existing commitment already visible. Propose reminders after **24 hours** and **72 hours**, then an admin summary of missing coverage; suppress reminders once committed capacity is sufficient. These are test defaults: no applicable published completion-rate uplift or optimal stakeholder reminder cadence was established.

**[Inferred] Decision:** Build an interviewer-level truth model and a compact capacity dashboard before adding more calendar overlays. A cluttered project calendar cannot answer whether recruitment has enough usable coverage.

## 5. Participant Outcomes, Evidence Limits And Failure Handling

### More choices are not automatically more useful choices

**[Inferred]** Zero-buffer, short-interval scheduling increases theoretical density, but participant conversion also depends on suitable local times, notice, trust, screening latency and whether the interviewer can honour the offer. Ten starts on the same morning are not equivalent to choices across days and evenings.

**[Research]** A **2 May 2025** retrospective ophthalmology study reports lower no-shows for online appointments in a private practice, **1.8% versus 5.9%**, but higher no-shows in the hospital, **14.3% versus 11.2%**. Hospital scheduling involved referral/triage workflows and was not directly comparable to self-service practice booking. This is a useful counterexample to universal automation claims, not an effect estimate for consumer interviews. [29]

**[Research]** Feldman and colleagues' **2014** preference/no-show paper combines modelling with patient stated-preference data; it does not establish an optimal number of research-interview slots. Its healthcare population and hypothetical choices limit transfer. **[Inferred]** There is no supported universal rule here such as three, five or ten participant choices guaranteeing good conversion. [31]

**[Inferred]** Measure the funnel from approval -> booking-page view -> usable choices -> booking -> attendance. Segment by participant zone, notice, device, study, interviewer connection mode and time from screening to approval. A useful coverage metric is the proportion of approved participants offered at least one feasible local-time option; test different choice counts rather than making one a launch requirement.

### Failure-mode acceptance criteria

| Failure | Established behaviour where verified | Recommended Sessions behaviour **[Inferred]** |
|---|---|---|
| Two studies book the same interviewer simultaneously | **[Documented]** Cal.com's own booked slots block across individual booking links. [57] | One interviewer-level reservation transaction; recheck eligibility and reject the losing request before confirmation. Use idempotency keys. |
| External meeting appears after availability was offered | **[Documented]** Calendar conflict checks constrain bookability. [3] | Recheck on booking; invalidate cached choices. If an already confirmed interview conflicts, alert the interviewer/admin rather than silently cancelling it. |
| Calendar disconnects or tenant consent expires | **[Documented]** Zoom's rotating-host documentation says an invalid host connection makes the schedule unbookable. [24] | Quarantine affected connected availability, preserve other hosts, and show the reason; allow an explicit switch to manual mode, never silent fail-open. |
| Interviewer leaves the pool | **[Documented]** dscout permits reassignment after launch. [27] | Separate removal from future allocation and transfer of existing bookings; notify affected people and retain an audit trail. |
| Availability added after recruitment starts | **[Documented]** dscout requires new post-launch slots to be published. [52] | Preview changes; publish intentionally; notify approved unbooked participants only when relevant new choices exist. |
| Cancellation or reschedule | **[Documented]** Doodle describes calendar updates on rescheduling. [54] | Release the old reservation only when the replacement is secured; update invitations, suppress obsolete reminders and apply cancellation policy. |
| Interview duration exceeds the grid step | **[Documented]** Vendors expose duration and cadence separately. [24] | Require the whole duration and chosen buffer to fit; never treat a free grid cell as a complete interview. |
| No available choices after approval | No universal remedy verified. | Explain the shortage; let participants request another time or join a notification queue; alert admins by affected segment. |
| Generic link bypasses screening | **[Documented]** Great Question's generic booking link can allow booking without a screener or prior invite. [14] | Use scoped, expiring approved-participant links; revalidate eligibility server-side. |

**[Inferred] Decision:** Treat capacity, booking confirmation and participant eligibility as transactional product logic. Calendar freshness alone cannot prevent races or protect the recruitment funnel.

## 6. Build, Cal.com Embed Or Microsoft Graph

### The options are not equivalent substitutes

| Dimension | Build Sessions scheduling in-house | Cal.com hosted embed / API | Microsoft Graph directly |
|---|---|---|---|
| Six internal problems addressed | **[Inferred]** Can solve P1-P4 and P6 directly; P5 requires a connector. | **[Inferred]** Potential authoring, slot and calendar components, but embedding a participant booker alone does not replace interviewer authoring or admin capacity UX. | **[Inferred]** Primarily P5 for supported Microsoft work accounts; does not provide P1-P4 or P6 UI. |
| UX control / branding | **[Inferred]** Full control, including manual and soft availability. | **[Documented]** Current Teams pricing lists custom APIs and branding removal. **[Inferred]** Standard iframe styling and API-built UX have different limits; confirm exact entitlement. [23] | **[Inferred]** No scheduler UI; Voxpopme owns design and branding. |
| Cost / licensing | **[Inferred]** Engineering, operations, accessibility, security and connector costs; no defensible total estimated here. | **[Documented]** Pricing page: Teams **US$12/user/month**, Organisations **US$28/user/month**, annual billing; Enterprise custom. These are hosted-plan prices, **not verified OEM/embedded-platform rights**. [23] | **[Inferred]** Integration/operations cost plus client Microsoft service prerequisites. No standalone Graph scheduling-price entitlement was verified; do not call this option free. |
| Platform availability | **[Inferred]** Under Voxpopme's control. | **[Documented]** Old Platform/Atoms closed to new customers; current hosted embed/API must be scoped separately. [26] | **[Documented]** `getSchedule` is a work/school free/busy API, not a booking engine. [4] |
| Provider coverage | **[Inferred]** Depends on connectors built/bought; manual can remain universal. | **[Inferred]** Require a current contracted provider matrix, including Apple requirements and non-connected hosts. | **[Documented]** This operation does not support personal Microsoft accounts. **[Inferred]** It does not solve Google or no-connection users. [4] |
| Enterprise consent | **[Inferred]** Necessary for whichever external connectors are added. | **[Inferred]** Vendor onboarding cannot override client tenant policy; consent is still a procurement risk. | **[Documented]** User-consent restrictions and app-only admin consent apply. [39][18] |
| Residency / privacy | **[Inferred]** Greatest control, but Voxpopme owns the obligations. | **[Documented]** Cal.eu migration/shutdown is planned for **1 Nov 2026**, with contractual enterprise exceptions. **[Inferred]** Require explicit regional/subprocessor terms. [60] | **[Inferred]** Microsoft account region does not determine where Voxpopme stores tokens, logs and availability. |
| Maintenance / lock-in | **[Inferred]** Highest scheduling-engine burden; lowest product-model dependency. | **[Inferred]** Less commodity engine work; vendor lifecycle, host identity, webhook semantics and commercial dependency remain. | **[Inferred]** Voxpopme still builds scheduling, concurrency, rescheduling, timezone handling and Google/manual support. |

### Procurement case: the old Cal.com proposition has changed

**[Documented]** The old Atoms proposition includes an availability editor and scheduling components, but current docs explicitly restrict it to existing customers. Meanwhile, Cal.com's public repository now presents **Cal.diy**, MIT-licensed, without Teams, Organisations, Workflows or SSO/SAML enterprise features. It is not evidence that the current commercial pooled scheduler can simply be self-hosted at no licence cost. [2][37]

**[Documented]** An official Cal.eu notice plans closure on **1 November 2026**, except where enterprise contracts extend access. Its byline and page metadata differ; the stated service-change date is explicit. The retrieved privacy policy also has a **future effective date of 1 November 2026**, so it should not be treated as the presently effective contract on this report's date. [60][47]

**[Inferred]** Keep an adapter boundary around any purchased engine: Voxpopme owns interviewer identity, approved-participant eligibility, study rules and an exportable booking ledger. Procurement should establish new-customer access, embedded/OEM rights, host pricing, branding, non-connected users, data region, service levels, webhooks, deletion/export and exit assistance before implementation.

**[Inferred] Decision:** Prefer a **Voxpopme-owned authoring and capacity experience with replaceable scheduling/connectivity services**. Run a commercial proof of concept for current Cal.com embed/API access, not deprecated Atoms. Graph is a useful Microsoft connector, never the complete alternative.

## 7. Eight Prioritised Design Changes And The Client Tests

**[Inferred]** These values are proposed starting defaults, not externally established optima. P1-P6 refer to the six internal problems in the brief.

| Priority / problem | Specific proposed design and defaults | Evidence | Success measure |
|---|---|---|---|
| **1. Range-first authoring - P1, P6** | Study-date list with visible checkboxes; start/end inputs; explicit bulk application. Optional suggested **09:00-17:00**, never silently saved. **44 x 44 px** day controls; keyboard/list alternative. | **[Documented]** Bulk/range precedents; **[Research]** target/drag guidance; **[Inferred]** implementation. [5][55][1][43] | Unassisted save rate, median completion time, wrong-day errors. Target **under 60 seconds** as a design goal, not a proven result. |
| **2. Duration-linked cadence - P2** | Default interval = duration: **15/15** or **30/30 minutes**. Put custom cadence in advanced settings; show complete candidate times. | **[Documented]** Doodle defaults to duration; **[Inferred]** Sessions default. [8] | Correct predicted starts/hour; invalid or overlapping-booking rate. |
| **3. Visible gap semantics - P3, P4** | Default **0 minutes before, 0 after**; clustering **off**. Show a sample booked session and next eligible start when changed. | **[Documented]** No-buffer precedent and contrasting buffer models; **[Inferred]** defaults. [8][3][52] | Rule comprehension, changes noticed, achievable capacity versus interviewer fatigue. |
| **4. Optional calendar connection - P5** | Offer Microsoft, Google and manual paths. Conflict checking **on when connected**; block offered windows **off**; write confirmed bookings **on where authorised**. Explain manual mode cannot see external meetings. | **[Documented]** Separate conflict/write patterns; **[Inferred]** flow. [56][46] | Consent success by tenant, abandonment, stale-connection time and external-conflict rate. |
| **5. Existing availability and provenance - P1, P5** | Show current-study offers, other-study bookings and past dates in distinct layers; copy previous availability only after review; never delete history merely because a date passes. | **[Research]** Recognition over recall; **[Inferred]** history model responding to internal signal. [41] | Can users find and explain previous offers? Duplicate/re-entered availability rate. |
| **6. Capacity-led admin view - P2, P4, scale** | Default availability-first assignment; least-loaded eligible host; proposed personal ceilings **4/day, 12/week across studies**, with explicit override. Start proposed study commitment at **3 interviews**, requiring confirmation. | **[Documented]** Pool/cap patterns; **[Inferred]** exact values and scope. [14][42] | Feasible coverage, assignment skew, quota shortfall and overload reports. |
| **7. Trustworthy global preview - P4, P6** | Preview interviewer and participant zones; use full dates and zone names; proposed minimum notice **24 hours**, editable per study. No publication until the user saves. | **[Documented]** Participant preview and zone patterns; **[Inferred]** notice/publication policy. [14][24] | Zone/date errors; preview-to-live consistency; same-day opportunity lost due to notice. |
| **8. Study-specific nudges - P1, P5** | Deep link with study duration/dates; optional usual-hours reuse; reminders at **24 and 72 hours**; then admin coverage summary. Stop once commitment is met. | **[Inferred]** Cadence unvalidated; no applicable completion uplift established. | Invite-to-save funnel, reminder opt-outs, incremental capacity and admin intervention. |

**[Inferred]** The zero-buffer default deliberately preserves four 15-minute interviews per hour; it is not a claim that continuous interviewing is best research practice. The 24-hour notice default favours enterprise reliability but may hurt rapid-turnaround recruitment. Test both tensions explicitly.

### What the evidence does not support

- **[Research - internal signal]** The internal task cannot establish client prevalence, causal failure rates or the best redesign. There was one recorded walkthrough and a small staff sample.
- **[Inferred]** P2 is not yet a diagnosed defect. Inspect duration, start interval, quota, gap, grouping, timezone and window-boundary logic before deciding why short interviews do not fit.
- **[Inferred]** A five-minute gap is not a harmless default; grid alignment can materially reduce capacity. Conversely, zero gap may harm note-taking and interviewer recovery.
- **[Inferred]** Neither an existing vendor label nor a heuristic proves wording comprehension. The proposed labels require client testing, especially whether grouping is a preference or a hard restriction.
- **[Inferred]** Live connection is not continuous consistency, and calendar access does not eliminate simultaneous-booking races.
- **[Inferred]** Availability-first, equal distribution, short notice and maximum choice cannot all be optimised simultaneously. Participant-local coverage matters more than a large undifferentiated slot total.
- **[Inferred]** The team may be overlooking observer constraints, accessibility, quotas by participant segment, late approvals after availability expires, consent-token expiry, employee monitoring concerns and support ownership when a purchased service fails.

### Open questions for real client interviewers

**[Inferred]** Recruit both frequent researchers and occasional departmental interviewers, including locked-down Microsoft tenants, Google users and people who refuse connection. Test the same end-to-end tasks, not preference questions alone:

1. Can they add three days of availability without discovering a hidden gesture, then correctly explain what was saved?
2. Do they understand the difference between interview length, start interval, total commitment and daily cap?
3. Does a gap mean recovery after a booking, space between every offered slot, or time reserved outside the offered window?
4. Does grouping mean back-to-back preference, mandatory consecutive sessions, or earliest-first allocation?
5. Will they honour a booking that conflicts with their external calendar when they explicitly selected manual/ignore-conflicts mode?
6. Can they find earlier availability and other-study commitments without concluding data disappeared?
7. Can a blocked calendar user complete the task while IT approval is pending?
8. Can admins identify a participant-zone coverage shortage and correct it without inspecting every interviewer calendar?
9. Can a travelling interviewer and a participant across midnight correctly read and reschedule the same appointment?

**[Inferred] Decision:** Compare range-first and explicit multi-day variants with realistic client calendars. Instrument comprehension, completion, feasible coverage and attendance separately; a fast authoring flow that produces unusable offers is not a success.

## 8. Synthesis: Buy Infrastructure, Own The Research Commitment

**[Documented]** General schedulers emphasise reusable personal schedules and booking rules; dscout demonstrates fixed study-slot authoring; Great Question exposes moderator-pool policies; Graph supplies calendar availability rather than a scheduling experience. These are different layers, not interchangeable products. [5][52][14][4]

**[Inferred]** Across **mechanism**, Sessions needs range authoring plus a conflict-aware reservation engine. Across **scope**, the interviewer is global across studies while each offer and participant approval belongs to a recruit round. Across **trade-offs**, fairness and recovery time can reduce participant choice. Across **operating horizon**, a calendar connector lowers future conflict risk but cannot repair today's confusing controls, while purchased components can lower maintenance only if their commercial lifecycle remains viable.

**[Inferred]** The non-obvious tension is that more automation can reduce trust: calendar authorisation can exclude busy stakeholders; fairness can hide real availability; stricter buffers can make an apparently generous window almost unusable; expiring overrides can erase the evidence users need to understand what they previously offered.

**[Inferred]** Therefore sequence the work: **range authoring and preview first; interviewer-level commitments and capacity second; optional Microsoft/Google connectivity third; procurement-backed engine substitution where it genuinely removes maintenance**. This respects the buy-not-build preference without outsourcing Voxpopme's distinctive responsibilities: eligibility, research commitments, participant experience and enterprise trust.

## References

Dates below are page publication/update dates where available. **Undated** means no reliable absolute date was stated. All sources were reviewed for this report on **20 October 2026**. Numeric citations above link individual claims to the relevant source.

### Vendor help documentation and changelogs

- **V1. Calendly, How to set your availability** - 20 Aug 2026. https://calendly.com/help/how-to-set-your-availability
- **V2. Calendly, How to fine-tune your availability settings** - 20 Aug 2026. https://calendly.com/help/how-to-fine-tune-your-availability-settings
- **V3. Calendly, How to use buffers** - 20 Aug 2026. https://calendly.com/help/how-to-use-buffers
- **V4. Calendly, Round Robin distribution overview** - 5 Oct 2026. https://calendly.com/help/round-robin-distribution-overview
- **V5. Cal.com, Set up your availability** - undated. https://cal.com/help/availabilities/availability-dashboard-overview
- **V6. Cal.com, Date overrides** - undated. https://cal.com/help/availabilities/date-overrides
- **V7. Cal.com, Round Robin Scheduling** - undated. https://cal.com/help/event-types/round-robin
- **V8. Cal.com, User-level booking limits** - undated. https://cal.com/help/event-types/user-booking-limits.md
- **V9. Cal.com, Troubleshoot your availability** - undated. https://cal.com/help/availabilities/troubleshoot-your-availability.md
- **V10. Cal.com, Link Specific Checking for Conflicts; Members Onboarding** - both undated. https://cal.com/help/event-types/eventtype-specific-checking-for-conflicts ; https://cal.com/help/enterprise/members-onboarding
- **V11. SavvyCal, Highlight preferred times** - 7 Aug 2025. https://docs.savvycal.com/article/95-optimized-availability
- **V12. SavvyCal, Introduction to SavvyCal** - 18 Jun 2024; **may be out of date**. https://docs.savvycal.com/article/63-introduction-to-savvycal
- **V13. SavvyCal, Configuring link availability** - 1 Jan 2025; **may be out of date**. https://docs.savvycal.com/article/26-configuring-buffers
- **V14. SavvyCal, Frequency limits** - 25 Aug 2024; **may be out of date**. https://docs.savvycal.com/article/117-frequency-limits
- **V15. Microsoft, Set Bookings scheduling policies** - 2 Apr 2025; **may be out of date**. https://learn.microsoft.com/en-us/microsoft-365/bookings/set-scheduling-policies?view=o365-worldwide
- **V16. Microsoft, Employee working hours in Bookings** - 10 Apr 2025; **may be out of date**. https://learn.microsoft.com/en-us/microsoft-365/bookings/employee-hours?view=o365-worldwide
- **V17. Microsoft, Add team members to Bookings** - 10 Apr 2025; **may be out of date**. https://learn.microsoft.com/en-us/microsoft-365/bookings/add-staff?view=o365-worldwide
- **V18. Google Calendar, Create an appointment schedule** - undated. https://support.google.com/calendar/answer/10729749?hl=en
- **V19. Zoom, Creating an Any Host Available booking schedule** - undated. https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0057781
- **V20. Doodle, Booking intervals and buffer times** - 11 Nov 2024; **may be out of date**. https://help.doodle.com/en/articles/9457375-how-to-use-booking-intervals-and-buffer-times-with-booking-page
- **V21. Doodle, Guide to Booking Page** - updated 28 Sep 2026; originally 30 Mar 2022. https://doodle.com/en/resource/how-to/guide-to-booking-page
- **V22. User Interviews, Set your availability and manage your research calendar** - 13 Jul 2026. https://www.userinterviews.com/support/manage-calendar
- **V23. Respondent, Calendar Availability** - 21 Apr 2025. https://help.respondent.io/en/articles/5485657-calendar-availability
- **V24. Great Question, Using the Scheduling Tool** - undated. https://greatquestion.co/support/studies/scheduling-tool
- **V25. dscout, Manage time slots in an interview study** - undated. https://help.dscout.com/interview-studies/create-an-interview-study/manage-time-slots-in-an-interview-study
- **V26. dscout, Tips for a successful interview session** - undated. https://help.dscout.com/interview-studies/conduct-an-interview-session/tips-for-a-successful-interview-session
- **V27. dscout, Assign or change moderators** - undated. https://help.dscout.com/interview-studies/manage-an-interview-study/assign-or-change-moderators-for-an-interview-session.md
- **V30. Rally, Revamped Study Scheduling** - 26 Jul 2023; **may be out of date**. https://www.rallyuxr.com/changelog/product-update-7-26-revamped-study-scheduling-and-more
- **V31. Ethnio, Scheduling Workflow** - 17 Jul 2026. https://help.ethn.io/article/164-scheduling-workflow
- **V32. Ethnio, Settings for Scheduling** - 17 Jun 2025. https://help.ethn.io/article/179-settings-for-scheduling
- **V33. UserTesting, Integrations overview** - 24 Jun 2026. http://help.usertesting.com/hc/en-us/articles/33784140732445-UserTesting-Integrations-overview
- **V34. Askable, Participant Screen Overview** - displays relative update wording, not a reliable absolute date. https://help.askable.com/en/articles/7221726-participant-screen-overview

### API and technical documentation

- **A1. Cal.com, AvailabilitySettings atom** - undated; deprecation warning. https://cal.com/docs/platform/atoms/availability-settings
- **A2. Cal.com, Platform FAQ** - undated; deprecation warning. https://cal.com/docs/platform/faq
- **A3. Microsoft Graph, calendar: getSchedule v1.0** - 23 Jul 2025. https://learn.microsoft.com/en-us/graph/api/calendar-getschedule?view=graph-rest-1.0
- **A4. Microsoft Graph, Permissions reference** - relevant entries undated. https://learn.microsoft.com/en-us/graph/permissions-reference
- **A5. Microsoft Graph, Get free/busy schedule** - 7 Nov 2024; **may be out of date**, including permissions guidance. https://learn.microsoft.com/en-us/graph/outlook-get-free-busy-schedule
- **A6. Microsoft Entra, Configure user consent** - 24 Jun 2025. https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent?tabs=azure-portal
- **A7. Microsoft Entra, Configure admin consent workflow** - 19 Jan 2026. https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-admin-consent-workflow
- **A8. Google Calendar API, Freebusy query** - 12 May 2026. https://developers.google.com/workspace/calendar/api/v3/reference/freebusy/query
- **A9. Microsoft Support, Import or subscribe to a calendar** - undated. https://support.microsoft.com/en-us/outlook/import-or-subscribe-to-a-calendar-in-outlook-com-or-outlook-on-the-web
- **A10. Cal.com public repository, currently presenting Cal.diy** - undated live repository. https://github.com/calcom/cal.com

### Usability research, accessibility and academic studies

- **R1. W3C, Understanding WCAG 2.5.8 Target Size** - updated 11 May 2026. https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html
- **R2. W3C, Understanding WCAG 2.5.7 Dragging Movements** - updated 10 Aug 2026. https://www.w3.org/WAI/WCAG22/Understanding/dragging-movements.html
- **R3. NN/g, Date-Input Form Fields** - 22 Jan 2017; **may be out of date**. https://www.nngroup.com/articles/date-input
- **R4. NN/g, 10 Usability Heuristics** - 24 Apr 1994; reviewed 30 Jan 2024; **may be out of date** as a dated source, not a current UI reference. https://www.nngroup.com/articles/ten-usability-heuristics/
- **R5. MacKenzie, Fitts' Law as a Research and Design Tool** - 1992; **may be out of date** for modern interaction particulars. https://www.yorku.ca/mack/HCI.html
- **R6. Betancor et al., Efficient patient care in the digital age** - 2 May 2025. https://pmc.ncbi.nlm.nih.gov/articles/PMC12081397/
- **R7. Feldman et al., Appointment Scheduling Under Patient Preference and No-Show Behavior** - 2014; **may be out of date** and indirect healthcare evidence. https://ziya.web.unc.edu/wp-content/uploads/sites/15166/2018/02/Feldman-Liu-Topaloglu-Ziya-2014.pdf

### Other: official commercial claims, policy and supplied evidence

- **V28. Lookback, All features** - undated marketing; recruitment scheduling claim, not detailed moderator help. https://www.lookback.com/all-lookbacks-features
- **V29. Rally, Scheduling** - undated marketing. https://www.rallyuxr.com/features/feature-scheduling
- **O1. Cal.com, Pricing** - page metadata 17 Oct 2026; prices are not an OEM quote. https://cal.com/pricing
- **O2. Cal.com, Cal.eu migration notice** - byline 30 Jul 2026; page metadata 17 Oct 2026; planned change 1 Nov 2026. https://cal.com/blog/cal.eu-to-cal.com-migration
- **O3. Cal.com, Privacy Policy** - retrieved version effective **1 Nov 2026**, future-effective on review date. https://cal.com/privacy
- **O4. ICO, Guide to data protection principles** - latest listed update 23 Mar 2026. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles
- **Internal Sessions study** - supplied in the brief; date not provided; 12 staff, one recorded walkthrough. Not independently published or linked.

## References

1. *Understanding Success Criterion 2.5.8: Target Size (Minimum) | WAI | W3C*. https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html
2. *Availability settings - Cal.com Docs*. https://cal.com/docs/platform/atoms/availability-settings
3. *How to use buffers | Calendly Help*. https://calendly.com/help/how-to-use-buffers
4. *calendar: getSchedule - Microsoft Graph v1.0 | Microsoft Learn*. https://learn.microsoft.com/en-us/graph/api/calendar-getschedule?view=graph-rest-1.0
5. *How to set your availability | Calendly Help*. https://calendly.com/help/how-to-set-your-availability
6. *How to fine-tune your availability settings | Calendly Help*. https://calendly.com/help/how-to-fine-tune-your-availability-settings
7. *Round Robin Scheduling*. https://cal.com/help/event-types/round-robin
8. *How to use booking intervals and buffer times with Booking Page | Doodle Help Center*. https://help.doodle.com/en/articles/9457375-how-to-use-booking-intervals-and-buffer-times-with-booking-page
9. *Create an appointment schedule - Google Calendar Help*. https://support.google.com/calendar/answer/10729749?hl=en
10. *Highlight preferred times - Meetings Help*. https://docs.savvycal.com/article/95-optimized-availability
11. *Introduction to SavvyCal - Meetings Help*. https://docs.savvycal.com/article/63-introduction-to-savvycal
12. *Calendar Availability | Respondent Help Center*. https://help.respondent.io/en/articles/5485657-calendar-availability
13. *Set your availability and manage your research calendar – Knowledge Base Home*. https://www.userinterviews.com/support/manage-calendar
14. *Using the Great Question Scheduling Tool*. https://greatquestion.co/support/studies/scheduling-tool
15. *Run Moderated Sessions | Lookback Help*. https://help.lookback.io/en/collections/18047630-run-moderated-sessions
16. *All Lookback's features*. https://www.lookback.com/all-lookbacks-features
17. *Manage an interview study*. https://help.dscout.com/interview-studies/manage-an-interview-study.md
18. *Microsoft Graph permissions reference  - Microsoft Graph | Microsoft Learn*. https://learn.microsoft.com/en-us/graph/permissions-reference
19. *Participant Screen Overview | Askable Help Center*. https://help.askable.com/en/articles/7221726-participant-screen-overview
20. *Set Bookings scheduling policies | Microsoft Learn*. https://learn.microsoft.com/en-us/microsoft-365/bookings/set-scheduling-policies?view=o365-worldwide
21. *Freebusy: query  |  Google Calendar  |  Google for Developers*. https://developers.google.com/workspace/calendar/api/v3/reference/freebusy/query
22. *Import or subscribe to a calendar in Outlook.com or Outlook on the web | Microsoft Support*. https://support.microsoft.com/en-us/outlook/import-or-subscribe-to-a-calendar-in-outlook-com-or-outlook-on-the-web
23. *Pricing | Cal.com*. https://cal.com/pricing
24. *Creating an Any Host Available (rotating host) booking schedule*. https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0057781
25. *Date-Input Form Fields: UX Design Guidelines - NN/G*. https://www.nngroup.com/articles/date-input
26. *FAQ*. https://cal.com/docs/platform/faq
27. *Assign or change moderators for an interview session*. https://help.dscout.com/interview-studies/manage-an-interview-study/assign-or-change-moderators-for-an-interview-session.md
28. *Scheduling | Explore Rally's Features*. https://www.rallyuxr.com/features/feature-scheduling
29. [
            Efficient patient care in the digital age: impact of online appointment scheduling in a medical practice and a university hospital on the “no-show”-rate - PMC
        ](https://pmc.ncbi.nlm.nih.gov/articles/PMC12081397/)
30. *Fitts' Law as a Research and Design Tool in Human-Computer Interaction*. https://www.yorku.ca/mack/HCI.html
31. *Appointment Scheduling Under Patient Preference and No-Show Behavior*. https://ziya.web.unc.edu/wp-content/uploads/sites/15166/2018/02/Feldman-Liu-Topaloglu-Ziya-2014.pdf
32. *Product Update 7.26: Revamped Study Scheduling and more*. https://www.rallyuxr.com/changelog/product-update-7-26-revamped-study-scheduling-and-more
33. *Settings for Scheduling - Ethnio Help Center*. https://help.ethn.io/article/179-settings-for-scheduling
34. *Scheduling Workflow - Ethnio Help Center*. https://help.ethn.io/article/164-scheduling-workflow
35. *Date overrides*. https://cal.com/help/availabilities/date-overrides
36. *UserTesting Integrations overview – Knowledge Base Home*. http://help.usertesting.com/hc/en-us/articles/33784140732445-UserTesting-Integrations-overview
37. *GitHub - calcom/cal.diy: Scheduling infrastructure for absolutely everyone. · GitHub*. https://github.com/calcom/cal.com
38. *Session rate card – Knowledge Base Home*. https://help.usertesting.com/hc/en-us/articles/11880342055965-Session-rate-card
39. *Configure How Users Consent to Applications - Microsoft Entra ID | Microsoft Learn*. https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent?tabs=azure-portal
40. *Employee working hours - Microsoft Bookings | Microsoft Learn*. https://learn.microsoft.com/en-us/microsoft-365/bookings/employee-hours?view=o365-worldwide
41. *10 Usability Heuristics for User Interface Design - NN/G*. https://www.nngroup.com/articles/ten-usability-heuristics/
42. *User-level booking limits*. https://cal.com/help/event-types/user-booking-limits.md
43. *Understanding Success Criterion 2.5.7: Dragging Movements | WAI | W3C*. https://www.w3.org/WAI/WCAG22/Understanding/dragging-movements.html
44. *Configure the admin consent workflow - Microsoft Entra ID | Microsoft Learn*. https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-admin-consent-workflow
45. *Get free/busy schedule of Outlook calendar users and resources - Microsoft Graph | Microsoft Learn*. https://learn.microsoft.com/en-us/graph/outlook-get-free-busy-schedule
46. *Add Staff*. https://learn.microsoft.com/en-us/microsoft-365/bookings/add-staff?view=o365-worldwide
47. *Privacy Policy | Cal.com*. https://cal.com/privacy
48. *Tips for a successful interview session*. https://help.dscout.com/interview-studies/conduct-an-interview-session/tips-for-a-successful-interview-session
49. *Configuring link availability - Meetings Help*. https://docs.savvycal.com/article/26-configuring-buffers
50. *Frequency limits - Meetings Help*. https://docs.savvycal.com/article/117-frequency-limits
51. *Troubleshoot your availability*. https://cal.com/help/availabilities/troubleshoot-your-availability.md
52. *Manage time slots in an interview study*. https://help.dscout.com/interview-studies/create-an-interview-study/manage-time-slots-in-an-interview-study
53. *A guide to the data protection principles | ICO*. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles
54. *Guide to Booking Page | Doodle*. https://doodle.com/en/resource/how-to/guide-to-booking-page
55. *Set up your availability*. https://cal.com/help/availabilities/availability-dashboard-overview
56. *Members Onboarding*. https://cal.com/help/enterprise/members-onboarding
57. *Link Specific Checking for Conflicts*. https://cal.com/help/event-types/eventtype-specific-checking-for-conflicts
58. *Blog - Explore Insights, Updates, and Use Cases | Cal.com Blog*. https://cal.com/blog/category/all-categories
59. *Round Robin distribution overview | Calendly Help*. https://calendly.com/help/round-robin-distribution-overview
60. *Cal.eu to Cal.com Migration | Cal.com - Scheduling Software for Online Bookings*. https://cal.com/blog/cal.eu-to-cal.com-migration