EMPIRE OPS × FUTURE CULTURE DESIGN CHECK

Booking & Appointment Management

Key considerations

Keep one appointment truth and make the client experience easier

Overview

Proposed pilot workflow

Book in Zandaappointment source of truth
→
Native calendar syncZanda → Eloise Google Calendar
→
New-booking notificationstructured automation trigger
→
Match + add clientexisting event only
→
Client gets invitecalendar follows Zanda changes
→
Routine changeClient Portal recommended
→
Exceptions to Adminagreed change returns to Zanda
Change pathway

Portal first, with a human fallback

Recommended: Client Portal

Clients use My Appointments for routine reschedules and cancellations. Zanda handles identity, the appointment, availability and the two-day policy boundary.

If the portal is not used

The client contacts a human Admin/practitioner. The request is handled manually and the agreed change is recorded in Zanda first. A dedicated appointments inbox is a later option, not required for the initial pilot.

Technology assessment

Several integration paths exist. The Google-side path now needs technical testing.

1. Direct Zanda API

Preferred when available for cleaner identifiers and state. Zanda’s public API is still restricted/beta and is read-oriented. Lack of API access does not block the calendar-invitation requirement.

2. Zanda native capability

Keep Zanda as the authoritative appointment record and retain its existing practitioner calendar sync and notification surfaces.

3. Google-side automation

Genuine candidate requiring testing. Zanda notification → Gmail/Google signal → extract minimum scheduling data → find the existing Google Calendar event → validate → add client attendee → log or route exception.

4. Additional automation tools if needed

Start with native Google functionality where it can meet the pilot requirement simply and avoid unnecessary platform cost. Make, Zapier, n8n or Power Automate can be introduced later if additional orchestration, monitoring or functionality is genuinely needed.

Detailed future-state flow

How the pilot would operate

Green · agreed / confirmedOrange · test / confirmGrey · client inputRed · blocked
HUMANAGREED DIRECTION

1. Book and manage the appointment in Zanda

Eloise creates the appointment in Zanda. Any later reschedule or cancellation is also recorded in Zanda first.
Why this way?
Zanda is the authoritative appointment record. We have confirmed Zanda → Google behaviour, but not a reliable Google → Zanda update path. A change made only in Google can therefore leave the systems out of sync.
Evidence / what we tested
Eloise confirmed first and subsequent EAP appointments are booked manually in Zanda. Controlled tests confirmed Zanda status and timing changes drive downstream calendar behaviour.
What we tried and ruled out
Do not use Google Calendar or a second automation-created event as another appointment source of truth.
TECHCONFIRMED

2. Use Zanda’s native Google Calendar sync

Zanda creates and maintains Eloise’s practitioner event in her existing Google Calendar.
Evidence / what we tested
CREATE created Eloise’s event. RESCHEDULE moved it. Proper cancellation changed the practitioner event to CXL. One cancellation propagation took roughly one minute.
Why this way?
The native integration already performs the practitioner-calendar work. Rebuilding it would duplicate capability and add failure points.
Q01 Client question · Cancelled appointments in your calendar
When an appointment is cancelled, Zanda currently leaves a CXL block in your Google Calendar. Do you find that useful, or would you prefer cancelled appointments to disappear if Zanda allows that behaviour to be changed?
Q02 Client question · Client information in Google Calendar
Zanda’s De-identify client details sent to Google Calendar setting is currently switched off. What client information do you actually need to see in your Google Calendar?
AUTOMATIONBUILD VALIDATION

3. Assess the Google-side booking signal

Candidate pathway: use Zanda’s new appointment practitioner notification as the booking signal. Google Apps Script is now a specific implementation candidate for reading the minimum required Gmail data and continuing the workflow entirely on the Google side.
Why not the Zanda API?
Direct API integration remains attractive for cleaner identifiers and state, but it is not required to add a client to an existing Google Calendar event. Zanda remains authoritative; the Google-side mechanism would only use an existing booking signal to locate and update the already-synchronised calendar event.
Evidence / what we tested
We temporarily enabled the practitioner notification and confirmed Eloise received it for a manually created appointment. Required merge fields for client email, practitioner and appointment timing are available.
What we tried and ruled out
We investigated the Zanda API, native automation-platform routes, hello@futureculture.com.au and broad inbox access. The API beta is currently restricted, hello@ is an alias rather than a standalone inbox, and broad inbox access is not appropriate. These constraints do not rule out a tightly scoped Google-side route.
Access required
The candidate Google Apps Script route would require authorised access to the Gmail mailbox receiving the booking notification and read/update access to the relevant Google Calendar. For the Eloise pilot, the confirmed practitioner notification recipient is Eloise. Test the least-privilege authentication model and whether a narrow label/search pattern can limit processing to the dedicated booking signal.
Risk / control
Avoid broad processing of Eloise’s general correspondence. The script must process only the minimum administrative scheduling data, use a dedicated subject/label/search condition, log outcomes without unnecessary client content, and stop on missing or ambiguous data.
Google Apps Script candidate
Candidate mechanism: structured Zanda booking notification → Gmail search/processing → extract minimum required fields → locate the existing practitioner Calendar event → require one valid match → add the client as guest → record success or route an exception.

Google Apps Script can search Gmail and can add a guest to an existing Calendar event when appropriately authorised. However, Apps Script does not provide a standard “new Gmail message received” installable trigger, so the trigger model itself needs testing, likely using controlled time-driven polling/search unless another supported Google event mechanism is selected. This pathway is not yet confirmed feasible end to end.
Q03 Client question · Weekly appointment volume
Roughly how many appointments do you personally create in Zanda in a typical week? Even a rough range is fine.
Q04 Client question · Lightweight automation check
Would a simple weekly email confirming how many appointments were created and how many client calendar invitations were successfully added be useful? The purpose would be to provide a simple check that the automation is still working. For example, if you normally create around 10 appointments a week and the report suddenly showed zero invitations added, it would be an obvious signal that something may have failed and needs checking. This would be a potential later paid enhancement, not required for the initial pilot.
AUTOMATIONBUILD VALIDATION

4. Validate the event match and add the client

Whichever Google-side implementation is selected, it must identify the existing Zanda-synchronised event, validate exactly one match, and then add the client email as an attendee. Google Apps Script is now one candidate for this action.
Why this way?
Without API identifiers, a deterministic composite match is the safest pilot approach. AI should not decide which calendar event is correct.
Evidence / what we tested
The structured Zanda fields are available and the corresponding event exists in Eloise’s synced Google Calendar. Manually adding Charlie as attendee sent a genuine Google invitation.
Access required
Read/update access to Eloise’s Google Calendar is required so the automation can search and update the existing event.
Risk / control
Exactly one event must match. Zero or multiple matches stop and route to Admin. Never create a second practitioner appointment.
Q05 Client question · Client calendar invitations
Are you comfortable with us automatically adding the client as an attendee to the existing Zanda-synchronised Google Calendar event? This is the approach we’ve tested to make sure the client’s calendar stays aligned when an appointment changes.
TECHCONFIRMED BEHAVIOUR

5. Let the client invitation follow Zanda changes

Google sends the client a genuine invitation. Once accepted, later Zanda reschedules and cancellations flow through the existing attendee relationship.
Evidence / what we tested
After Charlie accepted the invitation, a Zanda reschedule moved both Eloise’s and Charlie’s calendar event. Proper cancellation removed Charlie’s event while retaining the CXL block for Eloise.
What this replaces
The existing Gmail Add to Calendar experience can create an independent client copy that may become stale. The attendee relationship is the proposed fix.
Build requirement
Validate the complete email-trigger → unique-match → attendee-addition chain in the live build before production use.
TECHCLIENT DECISION

6. Use Client Portal for routine changes

Recommended pilot direction: clients use My Appointments in the Zanda Client Portal for routine reschedules and cancellations.
Why this way?
Zanda already handles client identity, appointment selection, availability and the two-day policy boundary. This is simpler than adding an AI-managed inbound appointment channel for routine changes.
Evidence / current setup
Client Portal is enabled. Reschedule and cancellation policy is set to Two Days Before Appointment. Eloise confirmed her clients are the group currently using the portal, although EAP bookings themselves are currently manual.
Access required
No new inbox access is required for routine self-service. Clients authenticate to the existing Zanda Client Portal.
If the portal is not used
The client contacts a human Admin/practitioner. The request is handled manually and the agreed change is made in Zanda first. A dedicated appointments inbox can be considered later if Future Culture wants managed inbound requests at scale.
Q06 Client question · Client Portal for routine changes
Would you be comfortable asking EAP clients to use My Appointments in the Zanda Client Portal for routine reschedules and cancellations?
Q07 Client question · How clients currently request changes
How do clients actually ask to change appointments today, for example text, email or phone, and approximately how often does this happen?
Q08 Client question · Services available through the Client Portal
Which of your EAP/LAP services should clients be able to reschedule or otherwise self-manage through the portal?
Q09 Client question · Practitioner restrictions
Should EAP clients only be able to book/reschedule with their assigned practitioner? We need to check this carefully because the relevant Zanda setting may also affect the contractor workflow.
HUMANAGREED CONTROL

7. Keep non-routine changes human-managed

Late, unusual, sensitive, series-level or otherwise non-self-serviceable cases stay with Admin and Eloise where practitioner judgement is required.
Human boundary
Admin can handle routine exceptions and administration. Eloise remains involved where practitioner judgement, relationship sensitivity or policy discretion is required.
System rule
Whatever the human decision, the authoritative change is recorded in Zanda first. Do not separately manage the appointment in Google.
Access / future option
A dedicated admin inbox does not currently exist because hello@ is an alias. If Future Culture later wants managed inbound automation, a real appointments/admin mailbox would be required.
Risk / control
Do not give AI broad inbox access merely to solve occasional exceptions. Agree a preferred client route and retain a clear human fallback.
TECHCLIENT DECISION

8. Use native communications where they work

Keep Zanda’s native booking and cancellation messages where they are adequate. Add deterministic communication only for demonstrated gaps.
Evidence / what we tested
CREATE confirmation works. Ordinary Cancelled status produced a client cancellation email. Manual reschedule produced no fresh explicit email. Late Cancellation produced no email in our A/B test.
What we found
Current appointment communication also presented multiple telehealth/Zoom details. Existing reminder wording includes seven-day exceptions that should not be encoded as policy without confirmation.
Q10 Client question · Telehealth link
Which Zoom/telehealth link should clients actually use? During testing we found multiple meeting details appearing in the current appointment communication.
Q11 Client question · Current cancellation policy wording
Are the seven-day exceptions currently included in the appointment reminder/cancellation wording still part of Future Culture’s policy? If so, when exactly should they apply?
Q12 Client question · Reschedule communication
If you manually reschedule an appointment in Zanda and the client’s calendar automatically moves to the new date/time, would you also like them to receive a separate email drawing their attention to the change?
Q13 Client question · Late Cancellation
What would you like the client to be told when an appointment is marked Late Cancellation, including what happens to that session within their EAP allocation?
EXCEPTION / CONTROLCLIENT INPUT

9. Keep availability and failures visible

Zanda availability must reflect what can actually be offered. Automation failures stop rather than guessing.
Availability finding
Eloise has regular weekly availability configured. Google-only commitments do not appear to provide Calendly-style continuous blocking of Zanda portal availability.
Automation exception
If the CREATE automation finds zero or multiple matching Google events, it stops and routes to Admin.
Risk / control
Do not add heavy availability automation unless real-world clashes justify it. Do not guess a calendar match.
Q14 Client question · Google Calendar versus Zanda availability
How often do you have commitments in Google Calendar that aren’t in Zanda, but fall within times Zanda would otherwise consider available for clients to book?
Alternative routeIf Future Culture does not want Client Portal for routine changes

The preferred pilot is still Client Portal. Open this section only if Eloise does not want routine reschedules/cancellations to use My Appointments. These are the workaround routes already considered, not additional pilot scope.

1. Human-managed through current channels

Clients continue to text, email or phone the practitioner/Admin. A human identifies the appointment and agrees the change, then records it in Zanda first. This is the simplest fallback and requires no new AI layer, but it preserves manual administration and inconsistent inbound channels.

2. Dedicated appointments/admin inbox

Create a real Future Culture appointments/admin mailbox rather than relying on the current hello@ alias. Routine requests could be centralised for Admin handling. This requires mailbox ownership, access, privacy, continuity and offboarding decisions.

3. AI-assisted inbound triage, later maturity

If residual request volume justifies it after a dedicated inbox exists, AI could classify requests and draft/route actions under the agreed human-agency boundary. This is not confirmed feasible and not required for the initial pilot.

4. Practitioner-direct remains the status quo

Future Culture could keep the current practitioner-direct model. It avoids new systems but gives the weakest standardisation and makes central visibility, privacy boundaries and scalable administration harder.

Design rule whichever fallback is chosen: the final agreed appointment change is made in Zanda first. Google Calendar remains downstream. Do not create a parallel appointment-management process in Google.
Remaining feasibility and testing

What Empire Ops still needs to review

1
Confirm the Zanda booking signal.
Verify that the relevant new-appointment notification is reliably sent for the in-scope booking routes, who receives it, whether the format is consistent, and whether it contains the client email, practitioner, appointment date/time and any stable identifier that can improve matching.
2
Test Google Apps Script as a genuine candidate.
Confirm the authentication model for the relevant Gmail and Google Calendar, the minimum OAuth scopes required, how the script will detect/process new booking notifications, and whether scheduled polling/search is reliable enough given Apps Script has no standard new-email installable trigger.
3
Prove deterministic event matching.
Test practitioner + client + exact date/start/end and any available stable identifier against real Zanda-synchronised events. Exactly one match may proceed. Zero or multiple matches must stop and route to Admin.
4
Prove attendee addition and invitation behaviour.
Confirm Apps Script or the selected Google-side mechanism can add the client as a guest to the existing practitioner event, that Google issues the conventional invitation, and that later Zanda reschedules/cancellations continue to propagate as already observed manually.
5
Test privacy, idempotency, logging and exceptions.
Process only minimum administrative scheduling data; prevent duplicate attendee additions; record success/failure without unnecessary client content; handle delayed calendar sync; and make failures visible to Admin.
6
Compare implementation routes before selecting one.
Compare Google Apps Script with any viable Make, Zapier, n8n or Power Automate route on permissions, reliability, maintenance, monitoring and cost. Do not select a platform merely because it is available.
7
Resolve the Late Cancellation communication discrepancy.
Our controlled test did not send the expected client email for Late Cancellation. Confirm configuration/vendor behaviour if this message is still required after the client communication decisions.
Design Check Closeout

Are we aligned on this future workflow?

If Empire Ops can complete the remaining review and prove the unresolved technical items work as described, is this the Booking & Appointment Management workflow Future Culture wants to operate?
  • Zanda remains the appointment source of truth. Create, reschedule and cancel there first.
  • Keep the native Zanda → Google Calendar sync for Eloise rather than rebuilding practitioner calendar synchronisation.
  • Turn on the structured new-appointment practitioner notification and use a controlled automation to add the client to the existing synced event, subject to build proof.
  • Use Client Portal for routine client changes if Eloise approves that experience; keep a human Admin fallback for exceptions and non-routine cases.
  • Use minimum necessary mailbox/calendar access and stop automation when a unique event match cannot be proven.
  • Keep native Zanda communications where they work and resolve only the demonstrated gaps in reschedule, telehealth and Late Cancellation messaging.
Eloise actions

What we need from Eloise

  1. Answer Q01–Q14 during the Design Check so the client decisions can be incorporated into the refined design.
  2. Confirm the preferred routine-change route, including whether EAP clients should use My Appointments in the Zanda Client Portal.
  3. Confirm the client communication rules:
    1. Confirm the one correct telehealth/Zoom link clients should receive. The current appointment communication appears to contain multiple meeting details.
    2. Confirm whether the existing seven-day exception wording is still current and, if so, exactly when it applies.
    3. Decide whether clients should receive a separate reschedule email when Eloise manually reschedules them. Our test showed the accepted calendar invitation moves automatically, but the client does not receive a new email drawing attention to the change.
    4. Confirm what a Late Cancellation means for the client’s EAP allocation and whether the client should receive an email explaining that consequence. Our test did not send the equivalent cancellation email for Late Cancellation.
  4. Confirm the Google Calendar appointment display, including whether cancelled appointments should remain as CXL blocks and what client information should appear in the appointment title/details.
  5. Confirm the operating volumes and calendar behaviour: roughly how many appointments Eloise creates in a typical week, and how often Google-only commitments fall inside times Zanda considers bookable. This tells us whether lightweight monitoring or availability automation is actually warranted.
  6. Approve the structured Zanda notification template once Empire Ops provides the proposed template. Technical testing will first determine the minimum Gmail/Google Calendar permissions required; Eloise will only be asked to approve/grant those permissions once we know exactly what is needed.
Later opportunities

Not required for the initial pilot

Weekly reconciliation and enhanced monitoring
A weekly report could show appointments created, successful client attendee additions and failed/unmatched cases. This is a later monitoring enhancement, not required for the initial pilot.
Google-only availability conflict automation
If Eloise regularly has non-Zanda commitments during bookable hours, a separate blocking solution could be investigated. Do not add this complexity unless Q14 shows a material operational need.
Dedicated appointments inbox + AI-managed requests
If Client Portal self-service leaves a meaningful volume of residual requests, Future Culture could later consider a real appointments/admin mailbox and AI-assisted triage. This has not been designed or validated for the initial pilot.
Additional practitioner / contractor rollout
The Eloise pilot should not be assumed to scale directly to contractors. A future rollout may need a central Future Culture appointments/admin mailbox and calendar, with practitioner-specific Zoom/telehealth configuration. Contractor calendar platforms, Zanda integrations, access preferences, duplicate prevention and CREATE/RESCHEDULE/CANCEL lifecycle behaviour would need separate investigation and testing before feasibility is claimed.
Direct Zanda API integration
Direct API access may later provide cleaner identifiers and reduce reliance on notification correlation, but it is not required for the Google-side invitation pathway. Zanda’s public API beta is currently restricted and the published capability is read-oriented.
Working Design Check. This artefact intentionally distinguishes established findings, proposed process rules, client decisions and technical testing still required. It is not yet the final agreed design.