Designing Focus Time Block Scheduling in Genesys Cloud WFM for Non-Phone Administrative Agent Tasks

How-To-Articles
1

Designing Focus Time Block Scheduling in Genesys Cloud WFM for Non-Phone Administrative Agent Tasks

What This Guide Covers

This guide details the architectural configuration of Focus Time blocks within Genesys Cloud Workforce Management (WFM) to accommodate non-phone administrative tasks without distorting occupancy metrics or adherence reporting. You will configure specific activity definitions, construct schedule blocks that isolate administrative capacity, and establish publishing rules that prevent these blocks from interfering with real-time adherence monitoring. Upon completion, the system will accurately track administrative labor hours as scheduled work rather than idle time, ensuring forecasting models reflect actual agent availability.

Prerequisites, Roles & Licensing

To implement this architecture, the organization must possess specific licensing tiers and granular permission sets. WFM capabilities for Focus Time are available under the WEM Premium license tier. Standard WFM licenses do not expose the granular focus time activity types required for accurate administrative task tracking.

Administrators require the following permissions within the Genesys Cloud Administration UI:

  • Workforce Management > Scheduling > Edit (To create and modify schedule blocks)
  • Workforce Management > Activities > Edit (To define custom Focus Time activities)
  • Workforce Management > Publishing > Publish (To push changes to the agent view)

For API-driven implementations, the OAuth scopes must include:

  • wfm:read
  • wfm:write
  • schedules:write

External dependencies include a clear definition of administrative tasks in the HRIS or ERP system. The WFM engine requires these activities to be mapped to specific activity IDs prior to schedule construction. Ensure that the Activity Type for admin tasks is distinct from standard Break types (e.g., Lunch, Short Break) to prevent automatic adherence rule violations during monitoring.

The Implementation Deep-Dive

1. Defining the Administrative Activity Structure

The foundation of Focus Time scheduling lies in the activity definition within the WFM backend. In Genesys Cloud, activities determine how time is categorized for forecasting and reporting. Creating a generic “Admin” activity without specific configuration leads to data corruption in occupancy calculations.

Architectural Reasoning:
Standard ACD Idle time represents agents waiting for contacts. Administrative tasks represent productive work that does not involve voice or chat interactions. If you configure an admin task as IDLE or OTHER, the WFM engine assumes the agent is unavailable for routing but counts it against scheduled capacity differently than a Break. To maintain forecast accuracy, administrative Focus Time must be treated as SCHEDULED WORK with specific adherence rules that exclude it from Real-Time Adherence (RTA) violations.

Configuration Steps:

  1. Navigate to Workforce Management > Activities in the Genesys Cloud Admin UI.
  2. Create a new activity named ADMIN_FOCUS_TIME.
  3. Set the Activity Type to WORK. Do not select BREAK or NON_CONTACT.
  4. Assign an Expected Capacity of 1.0 (100% productive). This ensures the agent counts as fully occupied during this block for forecasting purposes.
  5. Enable the Allow Focus Time toggle. This flag instructs the WFM engine to treat the activity as a planned block where agents are expected to be logged in but not receiving contacts.

The Trap: The most common misconfiguration is setting the Activity Type to OTHER or NON_CONTACT.

  • Downstream Effect: When an agent logs into this block, the system may flag them as “Not Ready” for routing even though they are scheduled to work. This creates a false negative in Adherence reporting where the agent appears to be violating schedule rules because they are not taking contacts during a time they are expected to be available.
  • Resolution: Always map administrative tasks to WORK type with Focus Time enabled. This signals the system that the capacity is consumed by work, not lost to downtime.

API Payload Reference:
When creating this activity via the REST API, ensure the payload reflects the work classification. The following JSON structure demonstrates the required field mapping for a valid administrative focus activity.

POST /api/v2/wfm/activities
{
  "name": "ADMIN_FOCUS_TIME",
  "description": "Dedicated block for non-phone administrative tasks",
  "type": "WORK",
  "expectedCapacity": 1.0,
  "focusTimeEnabled": true,
  "adherenceIgnoreRule": {
    "ruleType": "SCHEDULE_BLOCK_EXCLUSION",
    "description": "Exclude from RTA adherence calculations"
  }
}

Note the inclusion of adherenceIgnoreRule. This is critical for preventing false violation alerts during Real-Time Adherence monitoring. Without this rule, the system assumes any time spent in a scheduled block without a contact is a violation.

2. Constructing the Schedule Block Logic

Once the activity definition exists, the schedule block must be constructed to align with forecasted demand. In WFM, Focus Time blocks are often required during peak hours for quality assurance (QA) calibration or post-call wrap-up tasks that cannot be handled via standard Wrap-Up codes.

Architectural Reasoning:
Schedule blocks in Genesys Cloud WFM are not merely time slots; they are constraints on the optimization engine. When you define a Focus Time block, you are instructing the optimizer that this agent’s capacity is reserved for specific work and cannot be used to absorb incoming contacts. This directly impacts the Shrinkage calculation. If Focus Time is scheduled without proper configuration, it appears as unplanned shrinkage, which degrades the accuracy of future forecasts.

Configuration Steps:

  1. Navigate to Workforce Management > Scheduling and select the specific Agent Group or Employee View.
  2. Initiate a new Schedule Block for the target date range (e.g., 09:00 - 09:30).
  3. Assign the previously created ADMIN_FOCUS_TIME activity to this block.
  4. Set the Adherence Expectation to IGNORE. This setting tells the Real-Time Adherence engine not to generate a violation if the agent is not handling contacts during this specific window.
  5. Ensure the Shift Start/End times encompass the Focus Time block. The block cannot exist outside of the active shift hours.

The Trap: Administrators often attempt to place Focus Time blocks during peak traffic hours without adjusting the optimization constraints.

  • Downstream Effect: If an agent is scheduled for Focus Time during a high-volume period, the WFM optimizer will not assign them contacts. This reduces overall system throughput and increases Average Speed of Answer (ASA) because one fewer agent is available to answer calls. The forecast assumes this capacity is available; if the schedule overrides it, service levels drop immediately.
  • Resolution: Schedule Focus Time blocks during predicted lulls or specific windows where demand is below threshold. Use the Forecast > Demand view to identify low-volume intervals before locking in Focus Time blocks.

API Payload Reference:
When constructing a schedule block via API, the structure requires explicit linkage between the employee ID and the activity definition.

POST /api/v2/wfm/schedules/{scheduleId}/blocks
{
  "startTime": "2023-10-27T09:00:00Z",
  "endTime": "2023-10-27T09:30:00Z",
  "activityId": "ADMIN_FOCUS_TIME_ID_PLACEHOLDER",
  "employeeId": "EMPLOYEE_123456",
  "adherenceIgnoreRule": true,
  "publishState": "PUBLISHED"
}

Ensure the publishState is set to PUBLISHED if immediate visibility to the agent is required. If this is part of a bulk import, use DRAFT to validate against schedule constraints before pushing changes live. The adherenceIgnoreRule boolean field is critical here; omitting it causes the block to behave like standard work time regarding adherence monitoring.

3. Publishing and Overriding Schedules

The final step involves managing how these schedules interact with ad-hoc changes. Agents frequently require flexibility for unexpected administrative tasks that were not captured in the forecast. Rigid Focus Time blocks can lead to schedule adherence violations if an agent is pulled into a call during their admin block.

Architectural Reasoning:
The WFM engine supports two states of schedule interaction: Hard Constraints and Soft Constraints. For administrative Focus Time, you generally want Soft Constraints. This allows the Real-Time Dispatcher to override the Focus Time assignment if an emergency surge occurs, ensuring service levels are maintained at the cost of the scheduled admin task. Hard Constraints lock the agent into the block regardless of system load, which is rarely appropriate for operational WFM environments.

Configuration Steps:

  1. Navigate to Workforce Management > Scheduling Rules.
  2. Locate the rule governing Schedule Publishing.
  3. Modify the Adherence Violation Logic for Focus Time activities. Set the threshold to allow overrides without immediate penalty.
  4. Configure the Override Policy to require a manual confirmation from the Scheduler before an agent is reassigned from a Focus Time block during a surge.

The Trap: Failing to define an Override Policy creates a conflict between operational needs and scheduling integrity.

  • Downstream Effect: If an agent is pulled off their Focus Time block during a surge, the system may log this as a schedule violation for the agent (since they are no longer in their scheduled state) or a service level breach (if the override fails). This creates noise in adherence reports and damages agent trust in the scheduling process.
  • Resolution: Implement an explicit Override Policy that flags Focus Time blocks as “Soft” by default. Configure notifications to alert the WFM Team Lead when a Focus Time block is overridden so they can reschedule the admin task later.

API Payload Reference:
To modify the override policy via API, use the schedules/rules endpoint. The following payload demonstrates how to configure the soft constraint logic for Focus Time blocks.

PATCH /api/v2/wfm/schedulingrules/{ruleId}
{
  "name": "FocusTimeOverridePolicy",
  "activityType": "WORK",
  "activityNameMatch": "ADMIN_FOCUS_TIME*",
  "allowOverride": true,
  "overridePenaltyMinutes": 0,
  "notificationRecipients": [
    "scheduler@example.com"
  ],
  "enforcementLevel": "SOFT"
}

Setting enforcementLevel to SOFT ensures the optimizer attempts to respect the block but will break it if necessary for service level protection. The overridePenaltyMinutes of 0 ensures that agents do not incur adherence deductions when forced off a Focus Time block due to operational necessity. This distinction is vital for maintaining agent morale and accurate reporting.

Validation, Edge Cases & Troubleshooting

Edge Case 1: Occupancy Skew During High Volume

The Failure Condition:
Agents assigned to Focus Time blocks during peak hours show 100% occupancy in the system reports, yet the Average Speed of Answer (ASA) increases significantly.

The Root Cause:
The WFM engine counts Focus Time as occupied capacity (expectedCapacity: 1.0) but does not route contacts to those agents. During high volume, the forecasting model assumes this agent is available for routing. When the system cannot find other available agents, it routes to the Focus Time agent, violating the Focus Time rule. Alternatively, if the rule holds, the system under-serves the queue because it believes an agent is there when they are effectively unavailable for contact.

The Solution:
Review the Forecast > Demand view prior to publishing. Ensure that the total scheduled capacity (including Focus Time) does not exceed the expected demand during peak intervals. If the schedule must remain, adjust the Expected Capacity of the activity to 0.5 or lower, effectively telling the system this agent is partially available for routing if forced, though this reduces administrative time value. A better solution is to move the Focus Time block to a low-demand window identified in historical trend analysis.

Edge Case 2: Adherence Violation Loop

The Failure Condition:
Agents receive persistent adherence violation notifications despite being logged into their scheduled Focus Time blocks and not handling calls.

The Root Cause:
The adherenceIgnoreRule was either not applied to the Activity Definition or was overridden by a global Schedule Rule that enforces strict contact expectations for all WORK type activities. The WFM engine evaluates adherence rules hierarchically; if a global rule forces contact expectations, it overrides the activity-level setting.

The Solution:
Audit the hierarchy of Adherence Rules. Navigate to Workforce Management > Scheduling Rules > Adherence. Verify that no global rule is set to “Enforce Contact Expectations” for all WORK activities. Create a specific exception rule that targets only the ADMIN_FOCUS_TIME activity ID. Use the API to patch the adherence rule configuration to explicitly exclude this activity from contact expectations during scheduled blocks.

PATCH /api/v2/wfm/adherencerules/{ruleId}
{
  "description": "Exclude Admin Focus Time from Contact Expectations",
  "activityFilter": {
    "operator": "EQUALS",
    "value": "ADMIN_FOCUS_TIME"
  },
  "contactExpectationRequired": false,
  "ignoreDuringFocusTime": true
}

Edge Case 3: Forecasting Accuracy Degradation

The Failure Condition:
Forecasted required staff hours consistently exceed actual logged hours after implementing Focus Time scheduling.

The Root Cause:
Historical data used for forecasting still treats administrative time as “Non-Contact” or “Break” shrinkage, but the new schedule treats it as WORK. The WFM optimizer is now trying to fill these blocks with contact work because the forecast predicts that capacity should be used for calls.

The Solution:
Re-calibrate the Forecasting Model. You must update the Shrinkage settings in the forecasting module to account for the new Focus Time activity type. In the Forecast > Settings view, add a new shrinkage category for “Scheduled Admin Focus Time”. This tells the optimizer that this portion of capacity is intentionally removed from contact routing availability. Failure to update the forecast parameters results in an overstaffing scenario where the system predicts fewer agents are needed than are actually required to handle the remaining contact volume.

Official References