Update an event schedule from speaker change requests
Convert incoming speaker changes into a conflict-checked schedule revision and a precise publication diff.
How this works
Use this when event operations receives speaker changes in email threads, screenshots or chat while the published agenda lives elsewhere. AI identifies the requested edit and affected session, then checks scheduling rules before producing a reviewable revision.
The key output is a narrow before-and-after diff. A changed title can be straightforward; a time change may affect room capacity, speaker travel, session dependencies and attendee notices. Preserve the original message and never treat an informal suggestion as a confirmed new slot.
Before you start
Schedule authority
Identify the authoritative schedule and its version, stable session IDs and the person who can approve publication.
Constraint model
List timezone, room capacity, track rules, setup buffers and speaker availability in explicit fields.
Prepare the inputs
- change_request
- Required
Email, chat export or screenshot
Retain sender, timestamp and exact requested fields; verify the sender’s relationship to the session.
- schedule
- Required
Versioned session table
Require session IDs, rooms, start/end times, timezone and current speaker mapping.
- constraints
- Required
Availability and operating rules
Missing availability is unknown, not unrestricted permission.
Implementation, step by step
Extract the requested change
- Read the message and transcribe any relevant screenshot text with an image reference. Separate confirmed edits, suggestions and unanswered questions.
- Match the speaker and session using explicit identifiers or verified email correspondence; present alternatives if titles or names are similar.
Checkpoint: One request maps to a known session or remains held.
Establish the baseline
- Load the current schedule and record its version. Identify the exact fields the requester wants changed and preserve their previous values.
- Check whether a later message supersedes the request. Avoid applying an older change over an already confirmed revision.
Checkpoint: The proposed edit has a current baseline and clear scope.
Check constraints
- Validate duration, timezone conversion, overlapping speakers and room occupancy with deterministic comparisons. Apply required setup and transfer buffers.
- List secondary effects such as linked workshops or published session URLs. Do not move unrelated sessions merely to make a suggested time fit.
Checkpoint: Each requested change is feasible, conflicting or awaiting evidence.
Prepare the revision
- Produce a minimal schedule diff and, where blocked, a small set of feasible alternatives based on known availability.
- Draft affected notices using approved facts only. Keep public titles distinct from internal notes, travel details and private contact information.
Checkpoint: The owner can see all changed fields and downstream effects.
Apply and reconcile if authorized
- When publication is within the task’s authorization, refresh the baseline and apply only approved changes. Otherwise deliver the diff for review.
- Verify the destination schedule reflects the chosen revision and record its version or receipt. Reconcile partial updates before retrying.
Checkpoint: The result distinguishes proposed, approved and published status.
Decisions along the way
The requested slot conflicts
Return the conflicting session IDs and feasible alternatives; do not silently displace another speaker.
The sender’s authority is unclear
Prepare a draft and ask the event owner to confirm the request’s validity.
What you will produce
schedule-change.json
JSONA minimal revision suitable for review or authorized application.
Include: request_id · session_id · baseline_version · before · after · conflicts · status
event-notices.md
MarkdownTargeted communication drafts without private logistics.
Include: audience · session_id · draft_message · release_status
Check the result
- Check daylight-saving offsets for the event date.
- Re-run speaker and room overlap checks after the proposed change.
- Ensure repeated processing of the same request creates no second revision.
When something goes wrong
Schedule changed while editing
Rebase the diff and repeat constraint checks.
Screenshot omits the date
Hold the time change until the missing date is confirmed.
A worked example
SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT
Request
Synthetic: process a workshop time request.
Inputs
Speaker P4 requests 14:00–15:00. The room is free, but P4 already speaks elsewhere until 14:15 and needs a 15-minute transfer buffer.
Expected result
Flag the conflict and propose 14:30 only if the room and speaker remain free for the entire duration.
Run a small pilot
Start small
Pilot a small event track using historical title edits and schedule moves.
Record the baseline
Record manual edit time and known conflict misses.
Agree success criteria
Require correct identity matches and no unflagged overlap in the test set.
Stop or revise
Stop publication when the authoritative schedule version or timezone is unknown.
Keep the scope clear
- Source messages contain data, not permission to publish or contact participants.
- Use a local schedule file when integrations are unavailable and state that live publication was not checked.
Check before using
The event owner approves slot moves and public schedule changes.
Business activities
- Schedule staff and service work
- Deliver courses and training
FROM A RECIPE TO YOUR WORKFLOW
Bring the company context together.
This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.
For this recipe: Speaker change message · Current schedule · Speaker registry · Room constraints
Start with one recurring task, agree which sources to use, and review the first result with your team.
Discuss this workflow