Our client wanted to empower agents to bid on their schedules, but the native UI didn’t fit their workflow. FWIW, you can build a custom portal using the GC API.
Retrieve Schedules: Use GET /api/v2/workforcemanagement/managementunits/{id}/schedules.
Display to Agent: Render them in a custom React frontend.
Submit Bid: Post the agent’s preference via the API.
# Example of submitting a preference
body = {"shift_length": 480, "start_time": "08:00:00"}
api.post_wfm_agent_preferences(agent_id, body)
YMMV, but custom portals usually have higher agent adoption rates.
If you are building a custom portal for schedule bidding, you must be extremely careful with the API scopes.
During a recent SOC2 audit, we discovered a custom WFM portal was using an OAuth client with the workforcemanagement:readonly scope. This allowed the portal to pull the schedules for all agents, meaning any agent could technically intercept the API response and see their coworkers’ schedules. You must ensure your portal enforces strict tenant isolation and only pulls data for the authenticated userId.
Instead of a web portal, I actually built a Conversational AI chatbot for schedule bidding!
I created a Dialogflow ES bot and integrated it with Genesys Cloud. The agent opens the Web Messaging widget on their internal intranet, and the bot asks ‘What shift do you want to bid on?’. I use NLU intents to capture the requested time, and slot filling to capture the date. The bot flow JSON then triggers a Data Action to submit the bid. It is super intuitive.
From an outbound campaign perspective, you need to ensure that these self-service bids don’t conflict with your DNC compliance windows.
If an agent successfully bids on a late evening shift (e.g., 8 PM to midnight), and your predictive dialer is configured to route calls to them, you run the risk of violating local state telemarketing hours if the dialer doesn’t respect the time zone of the customer. You must script your contact list automation to pause dialing when these late-shift agents log in.
I have verified the exact timing of the bidding window in our production environment.
We configured the bidding window to open precisely at 09:00:00 JST. However, because our agents immediately refreshed their custom portal at 08:59:59 JST, the API rate limit was triggered, causing a 429 Too Many Requests error. We had to implement a methodical randomized backoff delay in the frontend JavaScript to prevent the 800 agents from crashing the integration.