Intraday Management: Business rules
Objective. Understand how business rules - alert thresholds, cost assumptions, policy constraints - shape what IDM flags, proposes and costs, and why the same day behaves differently under different rules.
Business rules is the configuration layer that governs IDM's judgement: what counts as drift worth an alert, what an action is assumed to cost, and which policy limits constrain the options a manager can take.
See it in the demo
What this screen answers
'Why does IDM flag what it flags, cost options the way it does, and allow or forbid certain actions?' This is the setup layer a CSM validates, not a daily driving screen. It encodes the thresholds behind alerts, the cost assumptions behind what-if figures, and the policy constraints - overtime limits, VTO rules - that bound what a manager may do.
The task
For a CSM, the task is to validate that the rules match the customer's real policy and cost reality: are alert thresholds set so the operation sees genuine drift without drowning in noise, do cost assumptions reflect the customer's actual rates, and do policy constraints mirror what the operation is actually allowed to do. For sales, it is awareness - enough to explain that IDM's behaviour is configurable and policy-bound, not a fixed black box.
How to read it
Rules are assumptions, not facts about the world. The same day will look calmer or noisier, and the same action cheaper or dearer, purely because of how these rules are set. The classic misread is treating an alert or a what-if cost as objective truth when it is the product of a configured threshold or rate. Read every downstream signal as 'true given these rules', and when a customer questions a figure, check the rule behind it before defending the number.
Honest limits
This screen configures behaviour; it does not guarantee the rules are right - that is a customer-owned validation. Which rules are configurable, who maintains them and how policy is enforced versus advisory is production-dependent - confirm with product. Exact rule types, cost-model fields and the demo content are SME-validation-pending; policy and cost rules are the customer's own.
Interpretation check
Alerts, what-if costs and allowed actions are all 'true given these configured rules', not objective facts - when a figure is questioned, check the rule behind it before defending the number.
In the field
OVO (contact centre): if the overtime cost assumption or the alert threshold is left at a default that does not match OVO's reality, every what-if cost and every alert on the floor is subtly off - which is why rule validation precedes trusting the numbers.
Practical task
On the demo, pick one rule type (an alert threshold or a cost assumption), and write a one-line validation question you would ask the customer to confirm it reflects their real policy or rates before trusting any downstream figure.
Self-check
A what-if shows overtime costing a certain amount. Is that the true cost?
It is the cost given the configured cost assumptions. If the customer's actual rates differ, the figure is wrong - validate the cost model before treating any what-if cost as truth.
One operation's alerts screen is noisy, another's is quiet, on similar days. What likely differs?
The alert thresholds configured in business rules. The same drift can flag or not depending on setup, so alert volume reflects configuration as much as the day itself.
A what-if proposes an action. What rule layer might still forbid it in reality?
Policy constraints - overtime limits, VTO rules - and whether those are enforced or merely advisory. Confirm with product; a projected option may not be a permitted one.
Why validate business rules at onboarding rather than assume defaults are fine?
Because every alert, cost and allowed action downstream is 'true given these rules'. Wrong thresholds or rates silently distort what managers see and decide across every other screen.
Verified vs demo. Screen is live in the demo at /#/rules; exact rule types, cost-model fields, enforcement behaviour and content are SME-validation-pending.