Workforce Management

When filtering by team, it changes the scheduled headcount on the staffing timeline to only reference team members. This also makes it so the net staffing is much less useful because you can't tell how moving members of your team would impact coverage more broadly, since the scheduled staffing shown is only your team and not reflective of other teams doing the work.

Currently, it's only possible to bulk apply to all child queues. But sometimes we want to apply the same adjusments across multiple parent queues. This would save us a lot of time, as often these adjustments are the same across many queues.

Ability to audit historical forecast uploads: was it successfully when was it uploaded ? By whom ? what was the file uploaded what was changed etc.

As a workforce manager, I need to be able to split forecasts by site to plan coverage.

Right now there is no way to over ride an manually put the AHT for emails that the forecaster wants the forecast to be. This needs to be changed because the forecast model is not going to be able to keep up with different types marketing or new hires that will have a higer AHT.

Ability for Assembled to forecast the max amount of volume a queue could handle while meeting SLA goals based on the current staffing levels

Allow custom percentage splits for capacity allocation across channels within a queue, rather than only equal splits. Customer request: Configure Admin Omni Support queue with 70% capacity for chat and 30% for email. Current limitation: Advanced capacity splitting only supports equal splits (e.g., 50/50 for two channels). Requested by: Canva (AG Vanguardia) Also requested by: Bullhorn (70/30 split), Dialpad (80/20 phones/email split)

We need forecast adjustments to influence upcoming weeks more immediately. Right now, when we adjust volumes for specific days or peak hours, the model takes several weeks to reflect those changes, which forces us to repeat the same manual adjustments over and over. A faster propagation option—or a clearer override mechanism—would help the forecast adapt in real time.

An example of the messaging here could be something like, "daylight savings time change in X region is occurring on X day. They will be falling back / springing forward X hours" perhaps two weeks ahead of these events.

Enable the recurring forecast job to project up to 1 year in advance. The current workaround involves using the forecast regeneration button, limited to 3 months with a 1-hour cooldown, which is time-consuming and very manual.