AI Scheduling Assistant for Executives: Link, Copilot, or Execution?

Run the hard-meeting buyer test in eight steps

Use one forty-five-minute executive customer council with the executive, EA, customer sponsor, technical lead, outside adviser, and optional observer. The group spans Google and Microsoft. One required person will not connect a calendar. One calendar changes after a slot is proposed. The EA must approve before booking.

1. 1

   Write the meeting brief and terminal proof

   Record purpose, duration, bounded date window, deadline, meeting time zone, required and optional people, approved substitutes, working-hour rules, buffers, protected executive time, location, disclosure, outreach policy, organizer calendar, approval mode, and exception owner. Define success as one correct event with verified invitations or one bounded decision returned to the EA.
   • A drafted email, poll response, selected slot, or tool success is not terminal proof.
   • The EA keeps priority, relationship, preparation, travel, and exception judgment.
   • Booking, rescheduling, and cancellation authority are tested separately.
2. 2

   Give every approach the same attendee geometry

   Preserve named required people, required roles, optional observers, and approved substitutes. Do not let a vendor demo turn the hard group into one host plus one invitee. Ask how the method represents the exact quorum and what happens when an optional person declines or a required role needs a substitute.
   • Required attendance cannot be relaxed to create more openings.
   • Optional attendance affects preference rather than validity.
   • A substitute change returns to the right approval boundary.
3. 3

   Test connected and unconnected availability together

   Use approved Google and Microsoft free/busy for connected people. Keep one external required participant unconnected and ask the method to collect bounded windows without a guest account or full calendar exposure. Check identity, time zone, consent, source, freshness, ambiguity, and how the response joins provider evidence.
   • Calendar connection is helpful and optional, not the product category.
   • Missing access or silence is not treated as open time.
   • Private event titles and unrelated attendee data stay hidden.
4. 4

   Inspect who owns the participant chase

   Start with incomplete availability. Observe who sends the first request, follows up inside approved cadence, parses corrections, handles a decline, stops on opt-out, and tells the EA what is blocking. A link may transfer action to the participant. A copilot may draft the next message. The buyer test follows the work until the group is ready.
   • Possessing an address does not grant permission to contact it.
   • Relationship-sensitive wording remains reviewable by the EA.
   • Every wait has a deadline, owner, and next safe action.
5. 5

   Force a priority, privacy, and time-zone exception

   Protect one executive window, make the external participant correct their zone, and add a sensitive reason for why Friday cannot move. Confirm that the method preserves the hard rule without publishing the private reason. Then ask it to explain no overlap and the smallest duration, date, attendee, or preference decision available to the EA.
   • The assistant never decides that protected time was merely a preference.
   • A participant correction invalidates stale proposals.
   • The exception card asks for one real decision instead of forwarding the thread.
6. 6

   Change a calendar after proposal

   Let the method produce a top slot, then place a conflict on one required Microsoft calendar. Approve only after the change. A dependable workflow detects stale evidence, rebuilds overlap, preserves valid participant responses, and returns the new decision. It does not trust a screenshot, old poll result, or model memory.
   • Fresh required free/busy is checked before any event write.
   • Unaffected participants are not chased again without cause.
   • The reason the proposal changed is visible to the EA.
7. 7

   Retry the booking and verify the invitation

   Repeat the approval or booking action and inject a timeout after the provider may have created the event. Check whether the system uses one idempotent booking command, reconciles provider state before retry, persists the canonical event identifier, and reads back time, zone, organizer, required people, optional attendance, and invitation dispatch.
   • A repeated action cannot create duplicate events or participant messages.
   • Partial or uncertain writes enter recovery rather than optimistic success.
   • The EA receives one final result with any bounded exception.
8. 8

   Measure net EA work after the meeting finishes

   Log request cleanup, calendar checks, availability requests, reminders, time-zone work, proposal, approval, event write, decline handling, repair, and software supervision. Separate active handling from participant wait and repetitive coordination from EA judgment. Compare local net time with WonderCal’s at-least-five-hour weekly target only after enough representative meetings exist.
   • Include setup, review, exception, and repair time in the ledger.
   • Do not count preparation, relationships, priority, or executive judgment as waste.
   • Reject an approach that saves clicks while adding supervision or calendar risk.

Booking link versus copilot versus scheduling execution

Compare the methods on the work boundary they own. The right answer depends on the meeting, but the buyer should know exactly where the workflow returns to the EA.