Workforce Management¶
Workforce Management (WFM) answers four questions about your contact center:
- How many agents will I need next week? — the Forecast answers this.
- Who works when? — you answer this, by building a rota out of shift patterns and assignments.
- Am I covered today, hour by hour? — Intraday answers this.
- Did the plan hold? — the Adherence report answers this.
Those four are stages of one loop, not four unrelated screens: the adherence you measure is where next week's shrinkage figure comes from.
Where the module lives¶
Portal → Contact Center → Workforce Management
Workforce Management runs in the Contact Center application, not in a section of the Portal. Selecting it in the Portal sidebar opens it in a new browser tab and signs you in automatically — you do not log in twice.
The same application also hosts Quality Management. When your account and role give you both, the Switch module button at the top of the sidebar moves between them without going back to the Portal. With only one module, the button is not shown.
The rest of the contact center stays where it is. Queues, agent states, campaigns and the reports are still configured and read in the Portal; this application covers scheduling and the numbers that drive it.
Turning it on¶
Two switches decide who gets Workforce Management. Both are needed.
- The account gets the module — Portal → Configuration → Accounts → (the account's CallCenter icon) → Workforce Management. The provider that manages the account decides this. The switch is shown only while Contact Center is enabled on the account, and with it off the module is not served to the account at all.
- A role is allowed to use it — see Permissions.
Working in a customer's account¶
The Contact Center application has no account switcher: everyone who works in it is a user of that account, and every schedule change is recorded under that user.
An administrator of a parent account who opens Workforce Management while working in a customer's account is first asked which of that account's users to act as. The application then opens as that user, and a bar across the top says who you are acting as for the whole session.
Who this page is for
Administrators and the supervisors who plan the roster. Agents get their own read-only view of the same plan, described in My Schedule.
Finding your way around¶
The sidebar has three groups, and the order is the working cycle rather than a list of stored objects:
| Group | Holds | For |
|---|---|---|
| Cycle | Today, Forecast, Plan next week, Schedule, Intraday, Adherence | The loop you run every week |
| Setup | Shift patterns, Assignments, Queues, Work profiles | The things the cycle reads |
| Wizards | Getting started, Plan next week, Why is my forecast empty? | Guided help when something is not adding up |
Every screen explains itself
Beside the title of every screen is an ⓘ button. It opens a panel with four things: what the screen is for, what you do on it, what it is not for, and links into the concepts behind it.
The what it is not for line is the one worth reading. On Plan next week it says that proposing, keeping and accepting change nothing — only publishing does. That is the single most common misunderstanding in the module, and it is answered before you can make it.
The ? button beside it opens the same panel at the conceptual guide on its own: how the module thinks, rather than which button to press.
Getting started¶
Wizards → Getting started
Until the required setup is done, the module opens on Getting started rather than on an empty grid. An empty agents-by-time grid tells a new administrator nothing about what to do next.
It is a default, not a lock: navigate away and you stay where you went.
The steps are an ordered chain, each one needed by the next:
| Step | Where it is done | |
|---|---|---|
| 1 | Classify your agent states | The Portal, not here — see below |
| 2 | Create a shift pattern | Setup → Shift patterns |
| 3 | Check who is in each queue | Setup → Queues |
| 4 | Put somebody on it | Setup → Assignments |
| 5 | Tell the planner about your agents — marked Recommended, not required | Setup → Work profiles |
A step you have finished keeps a quiet Review button, so you can go back to it.
\"Could not be read\" is not \"not done\"
A step whose state could not be read shows Could not be read and offers no button. It does not count as done, and it does not count as outstanding either — the module will not tell you the account is ready, and it will not send you back to the checklist on a guess. Fix the reason and reload.
Classifying your agent states¶
Portal → Contact Center → Agent States
This is step one, and the only step done somewhere else. Each agent state has a Productive switch: turn it on when time in that state is the work the agent is scheduled to do, and leave it off for breaks, training and meetings.
An unclassified state is read off the call-routing type
Until you classify a state explicitly, the module falls back to how the call router treats it — which counts anything that is not available as time away. A state such as On chat or Working is then measured as shrinkage, so an agent doing exactly what you scheduled looks like an agent who is not there.
The Getting started step names the states still in that position, so you do not have to hunt for them.
Step 1 is complete when every enabled state has been classified, not when one of them is productive.
Queue membership is part of the setup¶
Setup → Queues
An agent answers the queues they are a member of, and nothing else. That makes membership part of the roster, not a detail elsewhere — a beautiful rota of people who cannot answer the queue is not a rota.
The Queues screen is deliberately narrow: it lists queues and who is in them, and lets you change membership. Everything else about a queue — strategy, SLA, audio, wrap-up — stays in the Portal.
Its Rota column carries the warning worth acting on: n rostered but not a member. Those are people a shift pattern puts on this queue who cannot actually take its calls. Adding them here is one fix; taking the queue off the segment is the other.
How a rota is built¶
Three documents, not one¶
A rota is assembled from three kinds of document. Keeping them apart is what lets you say "next week the whole Sales queue starts at 10:00" without rewriting anybody's schedule.
| What it is | What it does not hold | |
|---|---|---|
| Shift pattern | A reusable week: name, timezone, and the segments of each weekday | No agents, no dates |
| Assignment | Who runs which pattern, between which dates | No shift times of its own |
| Exception | A dated overlay on one specific date — time off, training, a one-off meeting | Nothing repeating |
A segment is one block of a day: a start time, an end time, and the agent state expected in it. A break is just a segment whose state is Lunch — there is no separate break object, which is why the agent state list matters so much.
Shift patterns¶
Setup → Shift patterns
A pattern is a week you can hand to anybody. Because it holds no agents and no dates, one Early pattern serves every team that works those hours, and varying one person's week never means cloning it.
Rules to know:
Segments of the same day cannot overlap. If two segments both cover 10:00 there is no single answer to "what should this agent be doing at 10:00", and adherence would have nothing to measure against. The form blocks it.
A shift crossing midnight is two segments. A 22:00-to-06:00 night shift is written as 22:00 → 24:00 on one day and 00:00 → 06:00 on the next. The end time 24:00 means midnight closing that day.
Times are local to the pattern's timezone. A shift written as 09:00 stays at 09:00 through daylight-saving changes. Give each site its own pattern in its own timezone rather than converting times by hand.
A pattern an assignment still uses cannot be deleted. Remove the assignment first.
Which queue a segment serves¶
Each segment has a Serves setting. The default — any queue they are a member of — is what every segment meant before the setting existed, so nothing you have already built changes meaning.
Naming a queue narrows the segment to it, and the reason to do so is specific: for an agent who serves two queues, an unnamed hour is offered to both queues' plans as cover. Naming the queue is how you stop paying for the same hour twice.
Narrowing cover does not shorten the working day
An hour a segment gives to another queue is still an hour the agent is at work, and the planner still treats them as unavailable for anything else. The queue scope affects coverage only.
Staggered breaks¶
Assigning a pattern to a whole queue is right for the shift envelope and wrong for lunch: a whole queue at lunch together is a coverage hole. This is what the Take this in turns switch on a break segment is for.
Turn it on and the segment's start and end stop being the break and become the window the break may fall in. You then set how long each break lasts and how many agents may be away at once, and the editor says what that comes to: 3 turns of 2 — covers up to 6 agents without leaving the queue short.
- Which turn an agent lands in is stable, not random and not dependent on the order documents were saved. The same agent's lunch is at the same time on their own screen, on the supervisor's report and on tomorrow's re-read of the same week.
- A break longer than its window is refused when you save.
- An exception cannot carry a stagger. Its turns would be drawn from a group that exists only for that date, so an agent's lunch would move on the day they were given a meeting.
More agents than the window can hold
If the group is larger than the window and the away at once figure can absorb, the turns wrap round and more people end up away together than you asked for. That is deliberate — it is a real coverage problem, and it surfaces as a gap on Intraday rather than being hidden by squeezing breaks into slots that do not exist.
Assignments¶
Setup → Assignments
An assignment puts a pattern on a target, between two dates. The target is either named agents or a queue, never both.
Leave To empty for a standing rota. A queue-targeted assignment resolves its membership live: an agent added to that queue inherits the pattern with nobody editing anything.
Assignments are listed most specific first, each with a Precedence badge — Dated · agents, Dated · queue, Standing · agents, Standing · queue. A parked assignment is greyed and badged Parked; parking is how you take a rota out of use without deleting it.
Historical ranges use today's queue membership
Because queue membership is resolved when the schedule is read rather than stored on the assignment, a report over a past range resolves a queue-targeted assignment against who is in that queue now. An agent who changed queues last month is read with today's membership for the whole of that month.
Publishing a plan is what pins names down — see Publishing.
Which rota wins¶
Overlapping assignments are the normal case, not an error. For a given agent and day they are ranked, most specific first:
- A bounded window beats an open-ended one. A dated assignment always beats a standing one.
- Among bounded ones, the shorter window wins.
- Only at equal window length does an agent target beat a queue target.
The order of the first and third rules is load-bearing. Ranked the other way, "next week the whole Sales queue works 10:00–19:00" would lose to every standing personal assignment and silently apply to nobody.
The winner supplies the whole day, not the overlapping minutes. Merging two patterns minute by minute produces days neither author intended and nobody can predict from reading either one. Partial changes are what exceptions are for.
Exceptions are then laid over the resolved day, winning on the minutes they cover.
An exception segment with no state clears those minutes
That is how approved leave is expressed: the hours stop being scheduled at all, rather than being scheduled as something else, so they leave the adherence denominator instead of counting against the agent.
A genuine tie is still reported as a conflict
Two assignments with the same dates and the same authority, disagreeing about the state, are ambiguous and are surfaced as a conflict rather than resolved by guesswork. Everything that used to be a conflict because two schedules overlapped is now ordinary layering, so a conflict today is rare and is always an authoring mistake worth fixing.
When two queue rotas claim the same person¶
The Assignments screen warns before you discover it on the grid:
n agents are claimed by more than one queue rota — Ana — Sales and Support
Only one rota can apply to a person, so precedence picks one and reports the rest. The fix the screen recommends is to give that agent an assignment of their own: an agent target beats a queue target, whatever the queues say. People who already have a personal assignment are left out of the warning, because they are already resolved.
Work profiles¶
Setup → Work profiles
What the planner must respect about each agent. Every agent is listed whether or not they have a profile, and every field is optional:
| Field | Meaning |
|---|---|
| Contracted hours a week | What the agent is owed. Falling short is a cost the planner reports |
| Maximum hours a week | A hard ceiling |
| Minimum rest between shifts | A hard floor |
| Maximum days in a row | A hard ceiling |
| When they cannot, or would rather not, work | Per weekday time ranges, each either Cannot work or Would rather not |
The two strengths are the whole point of the screen. Cannot work is never traded; Would rather not is a preference the planner will break if it must, and will then tell you it broke.
Empty is not zero
Leave a box empty for no constraint. A zero is a different statement — a contracted week of zero hours would tell the planner to schedule that agent nowhere — and is refused rather than stored.
The Forecast¶
Cycle → Forecast
How many agents each interval needs to hit your service level target. It is the one screen that never looks at schedules — only at how much work has historically arrived.
For each interval, QVOICE Platform finds the same weekday and time of day in the past few weeks, averages the calls offered and the talk time, and works out the staffing that meets the queue's SLA target. The model is Erlang C, the industry-standard queueing formula — deliberately, because it is the model you can check against any online staffing calculator, and a headcount nobody can verify is a headcount nobody will trust.
Set the Day, the Shrinkage, how much History to read, and a Queue (or all of them).
Queue SLA comes from the Portal
Each queue is forecast against its own configured SLA target and threshold — answer X% of calls within Y seconds, set per queue in the Portal. A queue with none falls back to the convention of 80% within 20 seconds. A queue that really runs at 95% within 10 seconds, judged as 80/20, comes back understaffed in the one column that exists to say what it needs.
Reading the table¶
| Column | Meaning |
|---|---|
| Interval | The half hour |
| Calls | Forecast calls arriving in it |
| AHT | Average handle time the forecast used |
| Erlangs | The workload: calls × AHT ÷ interval length |
| Agents | What to roster, after shrinkage |
| Service level | The service level that staffing actually achieves |
Above the table, three cards summarise the whole day — the busiest interval, the agent-hours it adds up to, and how many intervals had enough history to answer. They do not change when you narrow the interval range.
\"Not enough history\" is not zero
An interval needs at least two historical observations before it is forecast. One Tuesday 09:30 is an anecdote — a public holiday or an outage would set your staffing for every Tuesday. Those intervals say not enough history and name the sample count. An interval that genuinely had no calls shows a real 0.
The interval-range filter¶
Two selects, From and To, sitting with the table rather than with the query controls — because they change nothing that is asked of the backend, only how much of the answer is on screen. A line above the table says Showing n of m intervals, with a Clear filters button, and only appears when something is hidden.
If the day's peak falls outside the window you chose, the screen says so rather than letting you plan against a quiet morning: The day peaks at 11:00 with 14 agents, outside this window.
The demand curve¶
Docked under the rows, on the same intervals: agents needed, per interval.
It is drawn in a single hue, because there is one series and colouring it further would imply a distinction that is not there. Two details are deliberate:
- An interval the forecast refused draws no bar. It draws shaded ground instead, and does not set the scale. A missing bar and a bar of zero are opposite claims, and the caption says which this is: Shaded intervals had too little history to forecast. They are not quiet hours — they are hours nobody measured.
- There is a mark on every interval boundary, taken from the data rather than assumed to be half-hourly, so you can see which bucket you are reading rather than estimating from a gridline every two hours.
Hovering an interval gives the whole row in a sentence — 09:00–09:30 · 42 calls at 180s · 9 agents needed.
The paired diagnostics¶
Under the controls sit two panels, side by side. Both answer the same question — is the number above trustworthy — from two different directions.
Measured shrinkage¶
Shrinkage is the share of paid time an agent is not available to take calls. Staffing without it understates what you need, and you no longer have to guess it: it is measured from the same weeks of history the forecast itself is built on, by comparing what your rotas planned against what agents actually did.
Three components, over one denominator — every second anybody was rostered:
| What it is | Staff for it? | |
|---|---|---|
| Planned away time | Breaks, training, meetings — somebody rostered them | Yes. It is on the rota and it is going to happen |
| Outbound campaign work | Rostered time spent on campaign calls | Yes. It is real work and it will happen again |
| Unplanned loss | Rostered productive time lost anyway — a late start, an unscheduled break, an absence | No |
The suggestion is planned plus outbound. The unplanned figure is shown beside them, greyed, because it is a number to manage rather than plan around. The panel says so itself: staffing for it makes it permanent. Hire an extra agent to cover the forty minutes somebody takes without asking, and the forty minutes becomes part of the establishment.
The suggestion is offered, never applied on its own
Nothing in the module silently swaps your chosen shrinkage for the measured one. You pick it.
A measured figure needs elapsed time, rosters and a sample of more than one person. When one of those is missing the panel says which, rather than leaving a silent blank, and you can still choose a fixed percentage by hand.
One pool, or separate queues?¶
The second panel answers the range twice — as one shared pool, and as separate queues — and reports the difference.
Erlang C is not linear. Three queues of five erlangs need eight agents each, twenty-four in total; the same calls answered by one interchangeable pool need nineteen. That difference is exactly what a pooled plan is saving by assuming your agents are interchangeable — and if they are not cross-trained, the saving is fictional and the queues are short.
The panel states both figures, splits them per queue, names the interval where the gap is widest, and refuses to choose:
Which figure is right depends on whether an agent on one queue can take another queue's call. If they cannot, the pooled figure understaffs by the difference — plan each queue on its own from the Plan screen rather than staffing to it.
It does not appear on an account with fewer than two queues, where the question does not arise.
A missing queue makes the sum unknown, not smaller
If the forecast refused one queue's interval, that queue drops out of the split and the total and the difference are reported as unknown rather than as a smaller number. A sum missing one of its terms is not a sum. A queue that genuinely had no calls still counts as a real zero.
What the forecast does not model¶
Worth knowing before you act on one:
- Public holidays are not modelled. A holiday looks like an ordinary weekday and pulls that weekday's average down. Check the forecast around known holidays by hand.
- Handle time is measured talk time. After-call work is not measured per call anywhere in the platform, so unless you supply an allowance the forecast understates what you need by roughly whatever wrap-up costs you. The Why is my forecast empty? wizard flags this one specially, because it is the only finding that makes the model ask for too few agents.
- A high historical abandon rate weakens it. Erlang C assumes callers wait indefinitely and never hang up. Where that is visibly untrue the model asks for more agents than reality requires — treat those intervals as an upper bound.
-
Outbound campaign calls are not arrivals, and are excluded. The dialler creates them at the rate you configure; they do not wait in a queue and do not abandon. Including them would answer "how many agents do I need to catch calls I cannot control" using calls you chose to make. The agent time they consume is not lost — it returns as the outbound component of measured shrinkage.
This is why the forecast does not tie out against the per-queue totals on an account that runs campaigns. It ties out against the Queue Calls report, which excludes campaign traffic too.
Plan next week¶
Cycle → Plan next week
The planner proposes a rota for a week, out of your patterns, your agents and the forecast. It is the only screen that writes a rota for you — and it writes nothing until you publish.
Set the week, a queue, the shrinkage and history the forecast should use, which shift patterns may be used, and one preference:
Rotation — how willing the planner is to move people. The slider names its own settings, from Reshuffle freely through Prefer stability and Keep people where they are to Move nobody unless forced. It defaults towards stability on purpose: a roster that reshuffles everyone weekly to save one agent-hour is arithmetically better and practically unusable, because people arrange childcare around a shift.
Plan each queue, not the contact centre
The queue picker defaults to Whole contact centre, which pools every queue into one forecast. That is only right if an agent on one queue can answer another queue's calls. Otherwise it asks for fewer agents than the queues actually need — by exactly the difference the Forecast's pooling panel reports.
The screen warns when you leave it pooled, and it names the people who serve more than one queue: Ana, Bea and Carla also serve another queue. A plan for that queue can roster them at the same hours as this one, and nothing will catch it.
What the planner will and will not trade¶
Some limits are never traded. An agent a pattern would push past one of them is not an expensive candidate, they are not a candidate, and the hour comes back as a coverage gap instead:
- more hours than their weekly maximum
- less than their minimum rest between shifts
- more consecutive days than they allow
- hours they cannot work
Everything else is a concession, and every concession comes back as a sentence in the What this plan cost panel, grouped worst first: hard limits the roster breaks, coverage left short, agents short of contracted hours, and preferences broken. Coverage gaps are reported per pattern — three short on Late is actionable, three short is not.
A plan that cost nothing says so plainly: This plan broke nothing: every shift is covered, no agent is short of their contracted hours, and no preference was overridden.
The planner is deterministic
The same inputs give the same rota. If a proposal changed, something you fed it changed.
Editing a proposal before you accept it¶
The proposal is not take-it-or-leave-it. In the roster table, the Shift cell of every row is a picker: swap an agent onto another pattern, or onto Not scheduled.
Every edit is re-scored. The whole roster goes back to be evaluated, and the concessions, the badges and the counts are all recomputed against the roster now on screen — nothing is scored in the browser. If the re-score fails, the screen says so and leaves your roster exactly as it was rather than showing you a rota with somebody else's numbers beside it.
Once you have changed anything, the proposal's provenance line records it: … Edited by hand.
You can break a hard limit; the planner cannot
The planner treats hard limits as infeasible and will never propose one. Editing by hand can create one anyway — and rather than refusing, the panel reports it in words: 8.5h of work against an 8.0h maximum, less than the 11.0h rest they need between shifts, more than 5 days in a row.
The header badges the count and warns before you keep it.
Rows are grouped by shift, biggest group first, alphabetical inside a group, with unrostered agents last — so the shape of the week reads at a glance instead of being reconstructed from a flat list. Each row carries a dot in its shift's colour, matching the badges above the table. A Change badge says what the plan did to each person: Moved, Left off, Newly rostered, Unchanged, with the pattern they came off named underneath.
Keep, accept, publish¶
The three controls sit together, top right of the proposal, and they are three different commitments:
| What it does | |
|---|---|
| Keep | Stores the proposal so you can come back to it. Changes nothing about anybody's week |
| Accept | Marks the kept plan as the one you intend to use. Still changes nothing |
| Publish | Creates the rota |
A published plan is terminal — it is never rewound. The correction to a published plan is a new plan.
Publishing changes the rota, and nothing else¶
This is the single easiest thing in the module to get wrong, so the module says it in three places and this page will say it again:
Publishing creates assignments. It does not staff a queue
Publishing writes assignment documents and nothing else. It does not add anybody to a queue, does not log anybody in, and does not change any agent's state.
The rota is descriptive. The queue actually has agents at 10:00 because those people arrived and logged in — the schedule is what you compare that against, not what causes it.
Two behaviours follow from doing it properly:
- One assignment per unbroken run of dates. Early on Monday, Wednesday and Friday creates three assignments, not one Monday-to-Friday assignment that would quietly roster Tuesday and Thursday too.
- Assignments name the agent, never the queue — a queue-targeted one would silently pick up whoever joins that queue next week.
Publishing is refused, naming the agent and the assignment it clashes with, when it would create a tie with a rota that agent already holds. Note how exact that is: an agent-targeted assignment can never tie with a queue-targeted one, so publishing a plan correctly overrides a standing queue rota instead of being blocked by it.
Schedule¶
Cycle → Schedule
The rota itself: agents down the side, the day across the top, each segment a block in its state's colour. Filter by agent or by rota, and step through days.
Underneath, on the same time axis, the coverage dock: agents needed against agents on shift, with the shortfall shaded and each run of it labelled. Edit the grid above and the curve below moves.
The coverage line is account-wide
Deliberately, and the screen footnotes it. Filtering the grid to one team does not narrow the coverage line — a line that narrowed with the filter would show a comfortable surplus on a day the contact center is short.
Today and Intraday¶
Today¶
Cycle → Today
The screen to open first thing. It answers one question — what needs you now — and deliberately holds nothing else: no volume, no AHT, no abandon rate, no occupancy. Those live in the reports.
When everything is fine it says so in one line: Every queue is covered for the rest of today.
Otherwise it lists Short right now and, separately, Short later today — the second in amber, with the point of showing it at all: Still time to move a break or ask somebody to start early. Each entry is a queue, an interval and a number: Sales · 14:00–15:30 · short by 3.
Below that, a table per queue of needed / rostered / at post, and a card summarising where next week has got to.
Intraday¶
Cycle → Intraday
The same forecast as the Forecast screen, put beside what you actually rostered and who is actually at their post, interval by interval, for today.
| Column | Where it comes from | Answers |
|---|---|---|
| Needed | The Erlang C forecast | How many agents this interval needs |
| On shift | Your rota | How many agents are rostered in a productive state |
| Gap | On shift − needed | The number to act on |
| At post now | Live agent state | How many agents are actually reachable right now |
The three columns are three different kinds of statement — a forecast, a plan and a live measurement — and the screen is careful not to let them blur:
At post now is only on the current interval
Attaching a live figure to 16:00 would dress the present up as a prediction. A supervisor would read it as "those agents will still be there", which nobody knows.
An absent live figure is not zero
When the live path is not answering, the column reads not reported and a banner says so. A stopped poller looks exactly like a contact center where everybody logged out, and reporting the second when the first is true is the worst mistake this screen could make. The forecast and rota columns do not depend on the live path and are still shown.
\"No data\" is not a requirement of zero
An interval the forecast could not answer shows No data, and its gap is blank rather than a comfortable surplus. A gap computed against an unknown is how a team gets stood down on a number nobody produced.
Narrowing the interval range does not hide the problem: n intervals outside this range are short. Narrowing the view does not narrow the day.
On shift counts productive time only. An agent rostered for lunch at 13:00 is on the rota but is not staffing the queue, so they are not counted for that interval. Counting them would report coverage that will not answer a call.
Adherence¶
Cycle → Adherence
The two percentages¶
Pick a day, and optionally filter by agent or by score. You get one row per agent with two different percentages. Both matter, and confusing them is the most common mistake on this screen.
| What it measures | Answers | |
|---|---|---|
| Adherence | The right state at the right time | "Were they where they were supposed to be, when they were supposed to be?" |
| Conformance | Enough hours, regardless of when | "Did they work their hours at all?" |
An agent who works a full eight-hour shift starting two hours late is 100% conformant and about 50% adherent. That is not a contradiction — it is exactly the distinction the two numbers exist to draw.
Conformance can exceed 100%
An agent who works ten hours against an eight-hour rota shows 125%. Overtime is surfaced, not hidden.
Worst first, and agents with no percentage sort last.
What it measures against¶
Adherence is measured against the Agent State the agent declared — the same catalogue of states your shift patterns are authored in, matched by state.
This is what makes the report mean what it appears to mean. A shift pattern says "this agent should be in Training"; the agent's own screen says they are in Training; and the report now compares those two directly rather than translating one of them into the call router's vocabulary of Idle, On call, Wrap-up and Logged out on the way.
Accounts with no Agent State history are unaffected
An account whose agents have never declared a state keeps the previous behaviour — measured from the call-routing timeline exactly as before. Nothing changes for them, and nothing needs to be done.
Where an agent does have a declared history, that is what they are measured against.
This measures what was declared, not whether the agent was there
An agent who sets themselves to Available and walks away scores as adherent. That is a deliberate and stated boundary, not an oversight: adherence measures whether the agent was in the state the plan named, at the time it named. Whether they were reachable, and whether they were busy, are different questions that the availability and occupancy reports answer.
The measurement depends on a database migration
Reading declared Agent States requires a design document — fonouc_agent_state — that an upgrade must create on the cluster. Where it is missing, adherence falls back to the old call-routing measurement and keeps working; it does not error, and there is no banner.
That silence is the risk: on an account whose agents use Agent States, the fallback can report a very low percentage against a plan the agents were demonstrably following. If the figures look wrong in that particular way, this is the first thing to check. Operators: see Agent State Views Migration.
What counts as adherent¶
- A segment scheduled as an available state is satisfied by any state where the agent is at their post and reachable — including wrap-up. An agent typing up the call they just handled is doing the job they were scheduled for, and penalising it would turn adherence into a measure of when calls happened to arrive.
- A segment scheduled as a specific away state — Lunch, Training — is satisfied only by that state. Taking calls during your scheduled lunch is a deviation from the plan even though it is productive work. That is precisely what separates adherence from conformance.
- Logged out never counts as adherent, because the queue cannot reach the agent.
The day, and the deviations¶
The Day column is a ribbon: the adherence band above, deviation marks below, with unplanned intervals left unpainted. Click a mark to open the deviations behind it — each with its own times, duration, what was expected and what happened instead.
| Exception | Means |
|---|---|
| Late start | Was not in the expected state when the segment began |
| Early end | Left the expected state before the segment ended |
| Absent | Never appeared for the segment at all |
| Over-long break | Deviated during a scheduled away segment |
| Unscheduled away | Went away during a scheduled available segment |
| Worked outside schedule | Was at their post when nothing was scheduled |
The percentage tells you how much was missed; the deviations tell you when, which is what you actually act on. A clean day says No deviations. The day went to plan.
Short deviations are forgiven, so a login twelve seconds late does not generate a row — a report full of trivia stops being read.
\"Not scheduled\" is not 0%
An agent nobody rostered for the period is not counted as failing. A zero would read as "worked their shift badly"; the truth is that there was nothing to work against.
Outside the module¶
Two surfaces outside the Workforce Management application read the same rota.
The agent's own view¶
Agents read their own shift in the user portal, and see a marker beside their status when they are not in the state their shift expects. That is what keeps the adherence report usable in a one-to-one instead of adversarial.
It has its own page: My Schedule.
The Supervisor Panel's Expected column¶
Once an account uses Workforce Management, the Agents table in the Supervisor Panel gains an Expected column beside each agent's current state: what the rota expects of them right now, in the state's own colour.
Put the two side by side and a break somebody forgot to come back from is visible at a glance, rather than the next morning in a report.
An agent with nothing scheduled at this moment shows an em dash. That is a different fact from "this account does not use Workforce Management" — in that case the column is not shown at all, and no account that will never use the module pays anything for it.
Permissions¶
Portal → Configuration → Roles → (a role) → Contact Center → Workforce Management
Workforce Management is a single Allowed / Denied switch, like Analytics. There are no sub-sections.
It used to offer four — one per screen — and they are gone because nothing enforced them. A role told that Capacity Planning was denied would still find the forecast in the next tab. A permission that is not enforced is worse than no permission at all, because it is read as protection.
The switch that remains is enforced by the server on every request, not only hidden in the screen: a role denied Workforce Management is refused even if somebody types the address directly, and the Contact Center application does not offer the module to it.
Quality Management, in the same application, has its own role section with two actions — see Quality Management → Turning it on.
Existing roles do not gain it automatically
Custom roles created before the module was installed will not have it, by design — nobody silently gains access to a new application. Turn it on for the roles that need it. Built-in roles with full Contact Center access receive it; the reports-only Contact Center roles are explicitly denied it, so a role meant for reading reports does not acquire schedule authoring on upgrade.
Frequently asked¶
Does publishing a plan put people in queues, or log them in? No. It creates the rota and nothing else. The rota is what you measure against; agents staff a queue by being members of it and logging in. See Publishing.
Do I have to schedule everyone before adherence works? No. Agents nobody has rostered are simply not measured, and are not counted as failing. Roster one team, learn from it, and expand.
Does the module build the roster for me? Plan next week proposes one, and you can edit it before you accept it. Deciding whether to take it is still yours, and nothing it proposes affects anybody until you publish.
Why does my plan ask for fewer agents than I expected? Most often because it was planned for the whole contact centre rather than per queue. Pooling assumes any agent can answer any queue. The Forecast's pooling panel reports exactly how many agents that assumption is saving you.
What is the difference between the Forecast and Intraday? The period, and what they compare against. The Forecast answers "how many agents will I need" for a future range. Intraday covers today and puts that same forecast beside what you rostered and who is actually at their post — a coverage check, not a plan.
Why does adherence disagree with my own count of someone's hours? Almost always because you are comparing it to conformance. Adherence penalises being in the right state at the wrong time; conformance does not. Check both before concluding a number is wrong.
Adherence shows a very low percentage for agents I know were working. Check that the account's Agent States are all classified, and that the cluster has run the Agent State views migration. Those are the two ways the report ends up measuring against something other than what your patterns are written in.
Why can I not delete this agent state? Because a shift pattern still uses it. The Portal names the patterns that reference it — edit those first.