How Startup Founders Stop Losing Deals to Multi-Person Sales Call Scheduling Lag

The Manual Tutorial: A Google Apps Script That Pulls an Outlook ICS Feed onto Google Calendar

Almost every founder who ships their own sync builds a version of this. The idea is direct: your AE publishes their Outlook calendar as an ICS feed, and a Google Apps Script running on a time trigger pulls that feed every 15 minutes and writes shadow "Busy" blocks onto your Google Calendar. Once both sides do the mirror-image setup, your co-founder's Google booking page never offers a slot the AE has already lost to a client call. That is the theory. Here is the build.

Follow these steps to get a working first version running in about 25 minutes:

1. Publish the Outlook ICS feed. In the AE's Outlook Web account, open Settings → Calendar → Shared calendars. Under Publish a calendar, choose the primary calendar, set permissions to Can view all details (needed so the parser can read start and end times), and copy the ICS URL. Store this URL somewhere private — anyone with the link can read the calendar.
2. Open Google Apps Script. Go to script.google.com signed in as the co-founder whose Google Calendar will host the shadow blocks. Create a new project and rename it outlook-ae-sync.
3. Paste the sync function. Replace the placeholder ICS URL with the one you copied. This script polls the Outlook feed, extracts VEVENT blocks with a regex, parses the start/end timestamps, and creates a masked event on the default Google Calendar for each conflict:

/**
 * outlook-ae-sync
 * Runs every 15 min. Pulls an AE's Outlook ICS feed
 * and writes masked 'Busy' shadow blocks onto the founder's
 * Google Calendar so booking pages hide the taken slots.
 */
function syncOutlookAeFeed() {
  var founderCal = CalendarApp.getDefaultCalendar();
  var outlookIcs = "https://outlook.office365.com/owa/calendar/REPLACE_ME/calendar.ics";
  var tagPrefix  = "[AE-BUSY]";

  var res, ics;
  try {
    res = UrlFetchApp.fetch(outlookIcs, { muteHttpExceptions: true });
    if (res.getResponseCode() !== 200) {
      Logger.log("Fetch failed: " + res.getResponseCode());
      return;
    }
    ics = res.getContentText();
  } catch (e) {
    Logger.log("Network error: " + e.toString());
    return;
  }

  // Regex parse of VEVENT blocks. Fragile, but works for basic feeds.
  var vevents = ics.match(/BEGIN:VEVENT[\s\S]*?END:VEVENT/g);
  if (!vevents) return;

  // Clean stale shadow blocks in the next 14 days before rewriting.
  var horizonStart = new Date();
  var horizonEnd = new Date();
  horizonEnd.setDate(horizonEnd.getDate() + 14);
  var existing = founderCal.getEvents(horizonStart, horizonEnd, { search: tagPrefix });
  for (var j = 0; j < existing.length; j++) existing[j].deleteEvent();

  for (var i = 0; i < vevents.length; i++) {
    var block = vevents[i];
    var dtStart = (block.match(/DTSTART[^:]*:([0-9TZ]+)/) || [])[1];
    var dtEnd   = (block.match(/DTEND[^:]*:([0-9TZ]+)/) || [])[1];
    if (!dtStart || !dtEnd) continue;

    var start = parseIcsUtc(dtStart);
    var end   = parseIcsUtc(dtEnd);
    if (!start || !end) continue;

    founderCal.createEvent(tagPrefix + " Do not book", start, end, {
      description: "Auto-generated shadow block. AE unavailable."
    });
  }
}

function parseIcsUtc(s) {
  // Assumes YYYYMMDDTHHMMSSZ. Ignores TZID — this is bottleneck #2.
  if (!/^\d{8}T\d{6}Z$/.test(s)) return null;
  var y  = parseInt(s.substr(0, 4), 10);
  var mo = parseInt(s.substr(4, 2), 10) - 1;
  var d  = parseInt(s.substr(6, 2), 10);
  var h  = parseInt(s.substr(9, 2), 10);
  var mi = parseInt(s.substr(11, 2), 10);
  var se = parseInt(s.substr(13, 2), 10);
  return new Date(Date.UTC(y, mo, d, h, mi, se));
}

4. Wire up the 15-minute trigger. In Apps Script, open Triggers (clock icon), click Add Trigger, choose syncOutlookAeFeed, event source Time-driven, type Minutes timer, interval Every 15 minutes. Save. Google will prompt for OAuth consent — approve CalendarApp and UrlFetchApp scopes.
5. Mirror it on the AE side. Repeat the same setup pointing the AE's Google Apps Script (or Power Automate flow) at the co-founder's published Google ICS feed so the block goes both ways. Without the mirror, only one calendar carries the shadow blocks and the other side can still overbook.
6. Test with a live conflict. Drop a real event on the AE's Outlook. Wait 16 minutes. Confirm the shadow block appeared on the founder's Google Calendar and that the public booking page hides that time.

At this point you have a working two-way shadow sync for zero dollars in software cost. Ship it, and for the first two weeks it will feel like the problem is solved. Then you start closing bigger deals, running more concurrent enterprise cycles, and the failure modes below start eating your pipeline.

Three Technical Bottlenecks That Break This Script Under Real Sales Load

Every founder who runs the script above eventually hits the same three failure modes in the same order. Knowing them ahead of time is the difference between losing a $60k ACV deal to a double-book and knowing exactly why the sync gap is not fixable at this layer.

1. The 90-Minute Daily Apps Script Quota and Its Silent Failure Mode

Google Workspace enforces a hard cap on total Apps Script execution time per day: 90 minutes for consumer and Workspace Starter accounts, 6 hours for Business Standard and above. A single run of the sync above takes 4-12 seconds on a light calendar. Add a second calendar to poll, add error retries, add a few dozen VEVENT blocks to parse, and you are at 20-40 seconds per run. Multiply by 96 runs a day (every 15 minutes) and you land in the 30-60 minute per day range.

The failure mode is what hurts. When you cross the quota, Google does not email you. It does not push a dashboard alert. It does not mark the trigger as suspended in the UI. It simply stops firing the trigger and writes a line into the executions log that nobody reads. Your Google Calendar drifts out of sync for the rest of the day and often the next morning, because the quota resets at midnight Pacific. Founders discover this at 9:15am on a Tuesday when the AE walks into a Zoom room that is already occupied by the co-founder's investor call.

2. Windows/IANA Timezone Parsing Bugs That Shift Blocks by an Hour

Outlook ICS exports emit two timezone conventions in the wild. The first uses UTC anchors ending in Z, which is what the script above handles. The second — much more common on Outlook desktop clients and on any calendar item created by a Windows user — uses a TZID parameter with a Windows-format identifier like TZID="Pacific Standard Time":20260702T140000 or TZID="Eastern Standard Time":20260702T140000.

The parser in the script ignores the TZID header. It reads the wall-clock time as UTC, so a 2:00 PM Pacific event lands on Google Calendar as 2:00 PM UTC, which is 7:00 AM Pacific — a shift of seven hours, not one. Even smarter parsers hit the harder version of this bug: Windows timezone names do not map one-to-one onto IANA identifiers, and daylight savings transitions happen on different dates in Windows zones vs IANA zones. Twice a year, every synced block shifts by one hour for one weekend, and the founder loses a Monday morning demo.

3. The 15-Minute Polling Latency Race Condition

This is the one that costs you deals. Google Apps Script time triggers have a floor of 15 minutes. You cannot poll more often. That 15-minute window is a race condition against every enterprise buyer holding your booking link.

Here is the exact sequence. At 10:02 AM the co-founder accepts an internal deal review on Outlook for 2:00 PM Wednesday. The next scheduled sync run is at 10:15 AM. Between 10:02 and 10:15, your Google-hosted booking page still shows 2:00 PM Wednesday as open. At 10:08 AM the buyer clicks the link and books it. Now you have two calendar-of-record entries for 2:00 PM Wednesday: the internal Outlook review and the external Google booking, held by two different humans on two different platforms. When the 10:15 sync runs, the script writes the shadow block on top of an already-confirmed external booking. Nothing fires an alert. The double-book is only discovered when the founder scrolls forward on Tuesday night.

At that point you have three options, all bad. Push the enterprise call and eat a two-week cycle slip. Push the internal review and burn your co-founder's prep time. Or split — one of you takes the demo alone without the technical answers the buyer asked for. Each option has a measurable cost in closed-won probability, and none of them are fixable by tuning the script. The 15-minute floor is a platform-level constraint.

Comparison: WonderCal vs Calendly vs Manual Apps Script / Invite Chains

The three approaches map onto three different points on the cost / control / reliability triangle. This table compares them across the five vectors that actually matter for a founder-led sales motion:

Deep Operational Comparison

The table above is the summary. What actually moves the needle for a founder-led sales team is how each system behaves during the moments that decide deals: the moment a buyer clicks the booking link, the moment enterprise IT reviews your OAuth scopes, and the moment the CFO asks why the calendar line item is $1,200 per year.

Why Database-Level Sync Beats Calendly's Real-Time Query Model on Multi-Calendar Users

Calendly's model is elegant: when a buyer opens a team booking page, Calendly queries each host's primary calendar in real time and shows only overlapping free slots. If your co-founder had exactly one calendar, this would be fine. In practice, a technical co-founder running sales cycles has at least three calendars in play — a personal Google Calendar, a company Google Calendar for internal blocks, and a client-facing Outlook calendar shared with a design partner. Calendly checks only the primary. The other two are invisible.

WonderCal fixes this at a different layer. Instead of asking Calendly to be smarter about which calendars to read, WonderCal mirrors events at the database level across every connected calendar in real time. When the co-founder accepts a meeting on the client Outlook, the shadow block lands on the primary Google Calendar in under 60 seconds. Calendly then queries the primary as it always did — but the primary now reflects true availability across all three calendars. You keep the Calendly booking experience your buyers already know and stop losing slots to the invisible-calendar bug.

How Narrow OAuth Scopes Get You Past Enterprise IT Where Broad Scopes Do Not

Every founder who has sold into a company with a security team has watched a deal freeze at the OAuth consent screen. The pattern is consistent: the buyer's CISO reviews the requested scopes, sees any scope that includes directory read, mailbox scan, or workspace-wide event management, and denies the connection. The AE calls you at 4:45 PM asking if there is a way to reduce scopes. Usually there is not.

WonderCal was designed around this. The OAuth request asks for calendar.events read and write on the connecting user's calendar only. No directory, no mail, no workspace admin, no user provisioning. When the buyer's IT team reviews the scope list they see exactly one capability and approve it in the same session. This is the specific reason WonderCal works inside client-hosted co-founder accounts where broader team-scheduling tools get denied.

The Real Cost of Seat-Tiered Pricing at Founder Team Sizes

Founder-led teams are seat-price sensitive in a way that later-stage companies are not. A $16 per seat monthly plan feels invisible when you have 300 sales reps. It feels expensive when the entire company is 6 people and every dollar of software spend competes with a candidate offer.

• 4-person founding team: Seat-priced plans cost around $768 per year. WonderCal costs $192 per year. Delta: $576.
• 10-person team (post-seed): Seat-priced plans cost around $1,920 per year. WonderCal costs $480 per year. Delta: $1,440.
• 25-person team (Series A): Seat-priced plans cost around $4,800 per year. WonderCal costs $1,200 per year. Delta: $3,600.

The seat delta is not the only cost. Seat-tiered plans also gate multi-host routing and team booking pages behind their higher tiers, which is exactly the feature founders need on day one. WonderCal ships multi-host routing at the base tier. You pay $4, you get the sales-team feature set.