Assembled Workforce Management

Customers need a fast way to delete events in bulk, filtered by event type and date range — a capability available in some prior WFM platforms. Current pain points: The only bulk-deletion method today (shift+drag on the schedule) also wipes PTO/time-off events, which is a hard blocker for teams that schedule far in advance and can't risk losing time-off data during cleanup. Filtering by event type and deleting only productive/default events has been attempted but does not fully preserve the time-off layer. This blocks workflows for rolling out Schedule Assistant team-by-team: filter by event type (e.g., coaching), mass-delete, re-add recurring events, then regenerate around them. Ask: A date-range + event-type filter that allows mass deletion of matching events, while always preserving the time-off/PTO layer.

Event timing rules relative to another event (e.g. "Back Office" after "Meal") require a minimum buffer of 6 minutes under "At least," with no way to set it to 0; a customer hit this wanting one event to always follow another but be allowed to land immediately adjacent to it when needed.

Before placing an event, Schedule Assistant should evaluate coverage for the relevant channels and queues and apply configurable priorities or minimum coverage thresholds. This would ensure that aggregate coverage does not mask a staffing gap in a critical queue or channel. Coverage-aware event placement would reduce manual scheduling work, improve confidence in Schedule Assistant recommendations, and help organizations avoid creating staffing gaps or SLA risk when scheduling trainings, meetings, breaks, and other events.

Add the ability for a weekly scheduling rule to place an event once per week within a defined set of eligible days and time window. For example: schedule one 30-minute meeting per agent each week on Wednesday, Thursday, or Friday, anytime between 1:00–5:00 PM, with Schedule Assistant selecting the best available time based on staffing and coverage. Today, weekly recurrence does not support this combination of constraints, while Custom Date Range rules require a more manual Schedule Assistant workflow and cannot be assigned to specific groups in advance. This would make recurring meetings, coaching, and training significantly easier to manage across teams with different availability windows.

The Assembled MCP server currently exposes tools to read schedules (get_schedule) and to create overtime/VTO opt-in slots (create_overtime_and_voluntary_time_off), but has no tool to create or assign a regular, named shift to a specific agent. We'd like a create_shift (or assign_shift) tool added so agents' pre-arranged shifts can be created programmatically instead of entered by hand in the Assembled UI. Use case 1: Holiday-break shift sign-ups Over the EOY holiday break, our Support agents sign up for specific shift times. Today this sign-up list lives in a spreadsheet, and each shift has to be manually entered into Assembled one at a time. We'd like to hand that spreadsheet to Claude and have it create each named, fixed-time shift directly via MCP. We've explored potentially using the overtime/VTO opt-in slots as a workaround for this spreadsheet, but that feature simply doesn't solve for our exact use case. Use case 2: Applying regional holidays to individual schedules We also want to bulk-apply regional/local holidays to the schedules of just the agents in that region — again, currently a manual, one-by-one process in the UI.

We have team the change channel based on a weekly rotation. For example; Week 1: Team A is on Phones, Team B & Team C are on Back Office tasks Week 2: Team B is on Phones, Team A & Team C are on Back Office tasks Week 3: Team C is on Phones, Team A & Team B are on Back Office tasks then repeat the cycle. Looking for a configuration solution through schedule rules to be able to reduce manual workload of this type of schedule rotation.

Productive event rules only control how work types are distributed within a shift, via context switching and per-shift or per-event time limits. There is no equivalent control across a week or month, so generation can assign the same agent to the same channel or event type week after week while other equally eligible agents receive none of it. Requested controls: Min/max hours or days per event type per week or month Max consecutive days or weeks on the same event type Desired weekly or monthly work-type mix Fair rotation across agents with equivalent eligibility Full-day event requirements, e.g. two Email days per schedule run

When we run Schedule Assistant, we need an aggregate before-and-after view showing what changed and how coverage (net staffing) was affected. I should also be able to compare pre- and post-optimization results across segments, queues, or lines of business, and see the events added, removed, or modified so we can review the updated schedule before publishing.

After a schedule change has been approved, the message received to agent is very generic. It only says " Hi ___, Your schedule has been updated. Please refresh to find out what is new" I dont understand the purpose of the description box in the Schedule Change Requests if it doesn't appear visible anywhere. Agents submit multiple changes in day and would like to know what specific changes were made.

When Schedule Assistant runs, agents with a time off event still receive a generated shift underneath the time off event. This is by design, so that coverage is already in place if the time off is later cancelled. Time off sits at the top of the event layer stack, so the consolidated schedule correctly shows the agent as out. When time off is removed. The current behaviour inherits a shift that may have been generated weeks earlier against requirements that have since changed. Some teams would rather decide whether that agent gets rescheduled at all, and for what, at the point the time off is cancelled. The underlying layer surfaces elsewhere in the product. When filtering the staffing timeline by channel or queue, agents who are out of office still appear in the agent count. Requested behaviour An account or team level setting to skip generation under time off events, so no shift is created underneath.