When event change requests are enabled for your Assembled instance, your agents will be able to request changes to their schedule.
Configuring event change requests settings
Admins can configure how event change requests work for their Assembled instance. They can choose whether to enable the feature, specify which standard role agents can request changes to their schedule, and specify which roles can action on requests.
The first dropdown allows setting which roles can action on requests. Anyone with the chosen role will be able to view, approve, and deny requests from all agents who are given access.
The event change requests page has filters that allow actioners to narrow down on the requests being viewed.
Admins can specify which agents will have access to request changes. They are able to grant access to all standard role agents, or choose to grant access to standard role agents who belong to specific queues, teams, or skills. This can be a helpful way to gradually introduce this new workflow into your organization.
Creating an event change request
Agents with the Standard role who are granted access can initiate event change requests on the My schedule page. Once they make changes on the calendar, they will see a “Request changes” button appear in the bottom right corner of the page.
Clicking this will open a modal where agents can specify who should be notified about the request (usually the person who will be approving the request, such as their direct manager). Agents may also specify an explanation about their request. Once the request is submitted, the specified people will be sent an email notification regarding the request.
Once created, agents may view their own requests in the Requests tab.
Agents may Cancel their request by clicking the trash can. Canceled requests cannot be approved or denied.
Future scheduling requests and revisions
Assembled will automatically categorize requests as being either Future scheduling requests or Revisions.
Future scheduling requests
These are changes which are made for a time in the future.
These are changes made for a time in the past. These are usually used when an agent did not end up doing what they were scheduled for, and they want to record what they actually did. For example, if an agent arrived late, or started early, they may want to create a revision to track the actual time they started.
Approving and denying event change requests
All people with the configured actioner role can view and action event change requests.
Clicking the check mark icon immediately approves the request, and the requested changes are applied to the schedule. The agent will receive an email notification regarding the request’s approval.
Clicking the cross icon opens a modal that allows for a denial reason to be specified. When the request is denied, the agent will receive an email notification.
Invalid and Expired requests
Requests can become Invalid or Expired.
Consider the following sequence of events.
- An agent request that their Phone event be lengthened by an hour.
- A manager changes that Phone event to be Chat instead, before the agent’s request was approved, denied, or canceled.
In this situation, the request is considered to be Invalid, since the schedule looks different from how it looked when the agent requested the change. The agent will receive an email alerting them that their request is now invalid. Once a request is invalid, it can no longer be approved or denied. If the agent still wants to make the change, they will have to create a new request.
A future scheduling request is considered Expired if it has not been approved, denied, or canceled by the time the request would have affected the schedule. Consider a future scheduling request which changes an event that starts at 10am. If the request has not been approved, denied, or canceled by 10am, it will be marked as Expired. Expired requests cannot be approved, denied, or canceled.