Group Meeting Scheduler for Cross-Company QBRs Across Vendor and Customer Tenants

Manual group meeting scheduler tutorial for cross-company QBRs

Run the manual method once for a single account. It will surface the operating rules a group scheduling tool has been quietly assuming for you. The working example is one 60-minute recurring QBR for a mid-market SaaS account. Required vendor roles are the CS lead, the AE, the founder-sponsor as the expansion approver, and the solutions engineer for the product review. Required customer roles are the economic buyer, the technical champion, and the procurement observer. Legal and product management may attend as informed observers.

1. Name the QBR outcome in one sentence

   Write the decision the QBR must produce. Pick one: renewal health check with a joint action plan, expansion readiness sign-off from the customer economic buyer, or at-risk save with a written mitigation plan and a pilot extension. Do not merge all three into a vague quarterly review. A QBR with three possible outcomes cannot enforce quorum, because the required roles change with the decision. Product Tevye rule: name the outcome before you touch a calendar.

2. Build the required-role matrix across vendor and customer sides

   List roles, not names. Names churn every quarter; the decision rights do not. Mark a role required only if the QBR cannot reach its stated outcome without that role. For expansion readiness, the customer economic buyer is required because they own the budget line, and procurement is required as observer because they will ask for paper the following week. Everyone else is optional or informed.

   Role	Side	Status	Representation rule
   CS lead	Vendor	Required	Named account owner, one approved backup
   Account executive	Vendor	Required	Renewal AE, no alternate for expansion
   Founder-sponsor	Vendor	Required	Founder for orders above threshold
   Solutions engineer	Vendor	Required	Named SE, one approved backup
   Economic buyer	Customer	Required	Named budget owner, no alternate
   Technical champion	Customer	Required	Named product owner, one approved backup
   Procurement observer	Customer	Required	Named procurement contact, informed observer
   Legal	Customer	Optional	Join only for paper questions

3. Confirm customer-side quorum in writing

   Send a short email to the customer technical champion. State the QBR outcome, list the required customer roles, and ask for written confirmation that the economic buyer and the procurement observer will attend. If the procurement observer cannot join a 60-minute call, ask whether the economic buyer carries procurement's authority for this QBR. Do not accept a verbal yes on a shared Slack Connect channel. Written customer-side quorum is the artifact that saves a QBR from being rescheduled at the last minute.

4. Create the shared conflict calendar for the account

   Create a calendar named QBR Busy - Account - QX, where QX is the fiscal quarter and Account is a short private reference key. The CS lead owns it. The AE, the founder-sponsor's executive assistant, and the solutions engineer contribute masked holds. The customer side does not connect. Customer-side blocking is handled through the approved windows from step 3, not through cross-tenant sharing between two separate Microsoft 365 or Google Workspace tenants.

   Restrict edit rights to the CS lead and one backup. A cross-company QBR calendar with five editors becomes a leak surface for account-plan detail inside a week.

5. Mask every hold and log the source calendar key

   Every hold on the shared conflict calendar shows title Busy. The record needs start, end, time zone, required role, source calendar key, and last-checked time. Do not copy customer names, ARR figures, expansion targets, board topics, investor calls, product incident bridges, hiring debriefs, or personal appointments. The source calendar key is a short private reference such as founder-g2, ae-o365, or se-workspace so the CS lead can trace a hold back to its origin without exposing the customer account name across the vendor pod.

6. Build 12 candidate 60-minute slots over 10 business days

   A 60-minute QBR needs 75 minutes of inventory: 60 for the call and 15 for founder-sponsor recovery time between the QBR and the next block. Start with 12 candidate 60-minute slots over the next 10 business days. Spread them across at least five days and two useful time bands for both the vendor and customer working hours. Give each slot an ID such as QBR-0722-1000-ET, an expiry time, and a status: open, held, booked, or released. This is the raw inventory before intersection.

7. Intersect required vendor calendars first, then customer windows

   Order matters. First intersect the CS lead, the AE, the founder-sponsor, and the solutions engineer across their Google and Outlook accounts. The founder-sponsor is the scarcest calendar in the vendor pod and should anchor the intersection. Second apply the customer-approved windows from step 3. Third apply buffers, time zones, and meeting length. Fourth check optional attendees. Optional roles may improve a slot; they must not erase all inventory. A slot that only works when legal happens to be free is not a real QBR slot.

8. Publish a short-lived 6-slot set with a 48-hour expiry

   Put 6 verified slots into the group meeting scheduler or send them to the customer technical champion. Expire the set after 48 hours during an active QBR cycle. If the customer needs more time, regenerate the intersection rather than trusting the previous day's view. Add a clear note that the link reserves a slot only after the confirmation email lands. A held slot is not a booked slot, and vote drift across a customer buying committee is what turns a 6-slot page into a stale calendar screenshot.

9. Run create, move, cancel, and race-condition tests

   Create a 45-minute founder-sponsor conflict on the source calendar and confirm the matching QBR slot disappears from the inventory. Move it and confirm the old slot reopens. Cancel it and confirm the inventory returns. Then open the booking page in two private browser windows and attempt to book the same slot at the same second. Only one booking should win. Repeat with an AE conflict, a solutions engineer conflict, and a customer window revision from the technical champion. Ship nothing that fails these four tests.

10. Name the audit and escalation owner

    One vendor operator, usually the CS lead, checks open inventory each morning, reviews holds older than 48 hours, removes expired slots, and escalates a failed calendar refresh. Write the fallback out loud: if quorum breaks inside four hours of the QBR, the CS lead asks the customer technical champion whether a written recap plus a 30-minute expansion-only call is acceptable, or reschedules with three new candidate slots. Do not surprise the customer economic buyer with a QBR that no longer includes the founder-sponsor.

Why the manual group meeting scheduler breaks at cross-company QBR scale

The manual method is useful because it forces the operating rules into the open. It also places every failure on one person. By the time three recurring QBRs each need a different founder-sponsor approval threshold and each customer runs its own procurement window, the shared conflict calendar becomes inventory control with a quarter of expansion revenue riding on every stale block.

Latency versus customer deal-desk cycles

Customer deal-desk cycles are narrow. A 60-minute QBR has to land inside a documented review window that runs 7 to 10 business days before quarter close for expansion paper to move. A manual calendar audit runs once or twice a day. The founder-sponsor's second Google account can pick up a board topic at 10:03 that the CS lead does not see until 10:40. A customer procurement observer who books at 10:20 has been offered a slot that no longer exists. That is a latency problem the vendor cannot solve with more discipline; it needs a shorter sync window.

Cache-driven false slots

The source calendar can be current while a subscribed ICS feed is old. The shared conflict calendar can be current while the group scheduling tool cached an availability response 15 minutes ago. The customer technical champion sees a green slot that reflects last week's truth. Record source, mirror, and buyer-facing verification times to find the lag. If the lag is longer than a customer deal-desk window is wide, the manual pipeline cannot support a recurring cross-company QBR at any account count above two.

Double-booking the founder-sponsor

The founder-sponsor is the scarcest calendar in the vendor pod. A single double-book on a QBR forces a re-poll of the customer technical champion, a new written confirmation from the economic buyer, and an internal apology to the procurement observer. It also teaches the customer buying committee that the vendor cannot coordinate its own room. That impression carries into the expansion conversation, where the customer economic buyer is asked to spend political capital defending a larger order across their own procurement and legal reviews.

Privacy exposure across account-plan notes

A shared conflict calendar with five editors is a slow leak of account-plan detail. Copied events reveal expansion targets, at-risk churn signals, competitive replacement calls, and deal-desk timing. The customer procurement observer must not see the vendor's internal renewal risk tag through a poorly masked title. Calendar exposure anxiety is real when the vendor pod cannot say with certainty which fields are visible in which tenant. The safe operating record is a generic Busy hold with a private source key held only by the CS lead.

Manual shared conflict calendar vs Calendly Collective vs WonderCal for cross-company QBRs

These three options solve different parts of the recurring QBR operation. The manual shared conflict calendar expresses the role matrix, the quorum rule, and the customer window record. Calendly Collective provides a customer-facing page that checks connected required-host calendars at the moment a slot is chosen. WonderCal keeps masked busy state aligned across every connected vendor Google and Outlook account, including the founder-sponsor's second work account, so the inventory the customer technical champion sees is current inside a minute. Most vendor CS pods run the booking page and the sync layer together, with the manual role matrix as the operating spec that neither tool tries to infer.