--- title: "Change Advisory Board Scheduling With AI Agents | Kylon" description: "How a change manager runs CAB scheduling, emergency changes, customer window moves, late clearances and the Friday cutoff in one Kylon room, with people approving." url: "https://kylon.io/use-cases/change-advisory-board" language: "en" --- [HOME](https://kylon.io/)\>[Use Cases](https://kylon.io/use-cases)\>Change Advisory Board: A Change Calendar That Absorbs Emergencies and Customer Requests Use Case9 min read # Change Advisory Board: A Change Calendar That Absorbs Emergencies and Customer Requests Weekly change requests are placed into maintenance windows under the CAB policy, emergencies displace by rule, customer requests move changes to the next open window, and the change manager approves every placement before ClickUp is updated. [Get started](https://app.kylon.io/sign-up) Kylon TeamProduct November 6, 2026 ## Two windows a week and a queue that never sits still Change advisory boards work from a compact policy. Standard changes go into the Tuesday or Thursday window, each window holds a set number of changes and only one high-risk one, a change needs an approved pull request and a rollback plan before it is placed, and nothing lands inside a customer's blackout. Applied on Monday, the policy produces a clean week. By Wednesday an emergency change has arrived, a customer has asked to move a date and a security clearance has come through late. Change requests live in ClickUp, the pull requests behind them in GitHub and the policy in Google Drive. Customer requests come into a shared Outlook mailbox, service teams post clearances in Slack, and the closeout emails go out from Gmail. The schedule is rebuilt by hand each time something moves, and the change that slips is usually the one an emergency displaced and nobody re-placed. ## Who works in the room People - Change manager Chairs the board, owns the CAB policy and approves every placement, displacement and carry-forward - Change coordinator Drafts the weekly agenda and runs each maintenance window - Service owners Raise change requests with a linked pull request and rollback plan, and confirm their windows - Customer success manager Brings customer window requests and confirms each new date with the customer Agents - RyanChange scheduler Places each ClickUp change request in a window under the CAB policy, checks the GitHub pull request behind it, and re-places changes when the week shifts ClickUpGitHubGoogle Drive - FinAgenda checker Checks the coordinator's draft agenda line by line against the approved schedule and lists every line that disagrees Google DriveClickUp - AdaChange correspondence Drafts customer replies in the Outlook change mailbox and per-service closeout emails in Gmail, and posts the approved schedule to Slack Outlook[Gmail](https://kylon.io/integrations/gmail) [Slack](https://kylon.io/integrations/slack) The board has one Kylon room, and Ryan is its default agent, so a new request or a question about a window goes to Ryan. Questions about the coordinator's agenda go to Fin, and anything that leaves the team, whether a customer reply or a closeout, goes to Ada, as the room guidelines say. Ryan hands each approved move to Ada by mentioning it in the thread with the moved requests listed, so a customer never hears about a date before the change manager has approved it. ## From Monday intake to the Friday cutoff Intake closes Monday at noon, and an automation opens the cutoff run on Friday at noon. In between, every placement is written to ClickUp only after the change manager approves it in the thread. ```mermaid flowchart TD place["Ryan places each request in a
window, or holds it with a reason"] ok1["Change manager approves
before ClickUp is updated"] agenda["Fin checks the draft agenda
against the approved schedule"] coord["Change coordinator corrects it,
change manager confirms"] emerg["Ryan re-places every change
an emergency pushes out"] cust["Ryan moves a customer's change to
a later window outside the blackout"] okchain["Change manager approves
the whole chain of moves"] okcust["Change manager approves the move"] amend["Ryan re-checks placements and
late clearances after an amendment"] reply["Ada drafts the customer reply"] okamend["Change manager approves
every changed placement"] csm["Customer success manager
confirms the date with the customer"] cutoff["Ryan retries each held or
deferred change once"] emails["Ada drafts one closeout
email per service"] final["Change manager approves the
carry-forward, sends each email"] place --> ok1 --> agenda --> coord coord --> emerg & cust emerg --> okchain --> amend --> okamend --> cutoff cust --> okcust --> reply --> csm --> cutoff cutoff --> emails --> final class place,agenda,emerg,cust,amend,reply,cutoff,emails agent class ok1,coord,okchain,okcust,okamend,csm,final person classDef agent fill:#FFFFFF,stroke:#DCD3C8,color:#1B1712 classDef person fill:#EEF0E3,stroke:#6E7447,color:#1B1712 classDef event fill:#F4ECDD,stroke:#F4ECDD,color:#564C42 ``` | Stage | What happens | Who acts | Who decides | | --- | --- | --- | --- | | Placement | Each request with an approved pull request and a rollback plan gets a window within capacity; the rest are held or deferred with a reason | Ryan, from ClickUp requests, GitHub reviews and the policy in Google Drive | The change manager approves before ClickUp is updated | | Agenda review | The coordinator's draft agenda is checked line by line against the approved schedule | Fin | The coordinator corrects it and the change manager confirms | | Emergency change | The emergency takes the next window under the emergency rule, and each change it pushes out is re-placed in the next window that fits | Ryan | The change manager approves the whole chain of moves | | Customer window request | The affected change moves to the first later window outside the customer's blackout that still has room | Ryan, then Ada for the customer reply | The customer success manager confirms the date with the customer | | Amendment and late clearances | Placed changes are re-checked under the amended risk rules, and held changes with a new clearance are placed if a window fits | Ryan | The change manager approves every changed placement | | Cutoff and closeout | Every retryable held or deferred change is retried once, then carried forward or cancelled, and each service gets one closeout email | Ryan, then Ada for the emails | The change manager approves the carry-forward and sends each email | Stages of one CAB week. Change numbers, windows and services in this example are illustrative. ## When an emergency or an amendment reshuffles the week An emergency is placed by its own rule: it takes the next window and pushes out the lowest-priority standard change already there. Ryan does not stop at the emergency. It re-places the displaced change in the next window with room, which can push out something else, and it shows the whole chain in the thread before anything is written. The change manager approves the chain, not just the first move. A risk-policy amendment is harder, because it changes the rules every earlier placement was made under. When the board decides that schema migrations now count as high risk, a Thursday window holding two of them is over its limit. Ryan re-checks every placed change against the amended policy, not only the ones the amendment names, and proposes the displacements in priority order. Late clearances that arrive in Slack the same afternoon are placed only if a window under the new rules still has room. ## What the checks catch - A displaced change that never got a new window because the emergency was the only move anyone recorded - A window over its high-risk limit after an amendment reclassified changes already placed there - A change placed inside a customer's blackout dates - A change marked ready whose pull request lost its approval after a new push - Held and deferred changes that reach the cutoff without their one retry ## What stays with people - Approving each placement, displacement and carry-forward before ClickUp is updated - Declaring a change an emergency, and cancelling a change instead of carrying it forward - Confirming a moved date with the customer and sending the reply Ada drafts in Outlook - Sending each per-service closeout email, which Ada prepares as a Gmail draft ## Integrations in this workflow Kylon is not a change management system, and it does not replace one. It works across the tracker, the code host and the mailboxes the board already uses, and keeps the coordination between them in one room. - ClickUp - GitHub - [Gmail](https://kylon.io/integrations/gmail) - Google Drive - Outlook - [Slack](https://kylon.io/integrations/slack) - **ClickUp** holds every change request with its risk level, window and status - **GitHub** shows whether the pull request behind each change is approved and passing its checks - **Google Drive** keeps the CAB policy, each amendment and the coordinator's draft agenda - **Outlook** is the shared change mailbox where customer window requests arrive and replies are drafted for a person to send - **Gmail** carries the per-service closeout emails, each sent by a person from Ada's draft - **Slack** is where service teams and security post late clearances, and where the approved schedule is shared ## Where to start Begin with one week of requests for one group of services. Connect the ClickUp space that holds change requests, give Ryan read access to the repositories behind them, and add one rule to the room guidelines: an agent may propose placements and displacements, and the change manager approves every one before ClickUp changes or anyone outside the room hears about it. > “The emergency still takes Tuesday. The difference is that the change it pushed out already has a new window, approved in the same thread.” ## Set it up with your agent Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it. Set-up prompt Set up our change advisory board desk in this Room. Take it one step at a time and wait for my OK before you move on. 1. Connect ClickUp, GitHub, Gmail, Google Drive, Outlook and Slack. Tell me which ones still need connecting. 2. Ask me who works this desk: the change manager, the change coordinator, the service owners and the customer success manager. Help me invite them to this Room. 3. Build a Change Calendar App with Requested, Scheduled, Held and Closed columns, one record per change request. Fill it from the open requests in ClickUp. 4. Check each request for an approved pull request in GitHub and a rollback plan. Check every placed change against our policy in Google Drive, the window capacity, the high-risk limit per window and any customer blackout dates. Show me every request that fails a check and propose a window, a status and a reason for each. 5. Draft customer replies in the Outlook change mailbox and per-service closeout emails as Gmail drafts. Post the approved schedule to Slack. Never send, post or write to ClickUp until the change manager approves each placement, displacement or carry-forward in the thread. 6. Write our rules, the approval order and who approves which send or ClickUp write into this Room's guideline, so every request follows the same steps. 7. After one clean week, offer to turn the cutoff run into an Automation. Before you start, ask me for our rules one at a time. [Get started](https://app.kylon.io/sign-up) Your first company harness. Where humans and agents run your business together. [Get started](https://app.kylon.io/sign-up) ## More Use Cases [View all](https://kylon.io/use-cases) [ ### API Deprecation Migration: Cutoff Waves That Stay Right as Integrations Move Retiring an API version runs through one Kylon room. Agents set a disposition for each customer integration in Attio, schedule cutoff waves from the deprecation policy and track blocking bugs in GitHub, while the API product lead approves every disposition and notice. Software & SaaSEngineering operationsEmail operations ](https://kylon.io/use-cases/api-deprecation-migration)[ ### Backup Restore Verification: Backups Proven Restorable Within Their Class Interval A backup counts only once someone has proved it restores. Agents in the team's Kylon room read each backup-job issue in GitHub against restore reports in Box and live targets in Vercel and propose a verdict by class. The reliability lead approves before any issue changes. Software & SaaSIT & security operations ](https://kylon.io/use-cases/backup-restore-verification)