Getting Works Council Sign-Off on Your Scheduling Software (Without a 6-Month Delay)

Getting Works Council Sign-Off on Your Scheduling Software (Without a 6-Month Delay)

Most Dutch companies discover that WOR Art. 27 applies to their scheduling software rollout six weeks after go-live, when the OR objects and freezes the data. The 6-month delay that follows is not caused by an obstructionist works council. It is caused by a structurally avoidable procedural mistake made on day one.

The good news: the OR's concerns are predictable, their demands are mostly reasonable, and the outcome of this negotiation is largely determined by the package you bring to the first meeting.

---

Why WOR Art. 27 Catches Scheduling Rollouts by Surprise

Article 27, lid 1, sub l of the Wet op de Ondernemingsraden requires formal OR consent before implementing any system that registers or monitors working time. Scheduling software that tracks actual hours, logs shift changes, or records attendance qualifies as such a system by default. There is no meaningful ambiguity here.

The mistake most companies make is framing the new software as a "tool upgrade." A planner moving from spreadsheets to a SaaS platform, or from one scheduling tool to a newer one, often presents this internally as a technical replacement rather than a new system. That framing skips the OR process entirely. And when the OR finds out — usually through an employee who notices their absence history being discussed in a meeting — they are not wrong to object.

Post-implementation discovery is the worst possible scenario. The OR can challenge the legal validity of time data used in employment disputes, creating retroactive exposure for any disciplinary or dismissal proceedings where scheduling records were cited. I have seen this exact problem at a mid-sized retailer whose OR successfully argued that all time-registration data collected in the six months before instemming was obtained without consent and could not be used in a dismissal case. The dismissal held anyway, but it cost significantly more than the six-week OR process would have.

Companies with fewer than 50 employees have no formal OR obligation, but those with a personeelsvertegenwoordiging (PVT) face a lighter version of the same dynamic. The PVT has a right to consultation, not formal consent, but ignoring them creates the same trust breakdown.

---

What the OR Is Actually Worried About

Before preparing your instemmingsverzoek, understand what is driving the other side of the table.

The primary concern, almost universally, is whether shift data will be used against employees. Not in some abstract future sense, but concretely: can a manager pull up an employee's attendance history during a performance review? Can late clock-ins appear in a dismissal file? Works council members have usually seen this happen with a previous system. They are not being paranoid.

The secondary concern is access scope. Who in management can see individual employee schedules and attendance records? If a regional director can browse any employee's shift history across 12 sites, that is a different system than one where access is role-limited and audited.

The third concern, more common now than it was five years ago, is algorithmic transparency. When auto-scheduling assigns someone a difficult shift pattern or consistently gives certain employees the less desirable weekend slots, who is accountable? Is there an audit trail? Can an employee see why they were assigned a particular shift?

Here is the practical insight: most OR committees have already had at least one experience where a system was used in ways that were never disclosed upfront. The distrust in the room is not about your specific software. It is about a pattern they have already lived through. Acknowledging this explicitly — and then specifically addressing how your implementation is designed differently — builds more credibility than any contractual guarantee.

---

The Four Documents That Make OR Consent Go Faster

Companies that prepare these four documents before the first OR meeting complete the instemming process in six to eight weeks. Companies that arrive without them spend months going back and forth while the OR commissions its own research.

A Data Protection Impact Assessment (DPIA). Under GDPR, a DPIA is required for any systematic monitoring of employees. Having it done before the OR meeting does two things: it signals good faith, and it saves the OR their own research time. If your OR has a privacy-conscious member (and most do), the first question will be whether a DPIA was conducted. Arriving with one changes the entire tone of the meeting.

A data minimisation statement. This is a written document specifying exactly which data fields are collected, how long they are retained, and who can access what. The specificity matters more than the breadth of promises. "We only collect the minimum necessary data" is meaningless. "The system collects scheduled shift start/end times, actual clock-in/out times, and shift change history; data is retained for 24 months; individual-level records are accessible only to direct line managers and HR; aggregate anonymised data is accessible to operations management" is something the OR can evaluate.

A dispute-use policy. This is a formal statement, ideally annexed to the instemming agreement itself, defining the circumstances under which scheduling data may and may not be used in individual employment disputes. Most ORs will accept language permitting use to verify compliance with CAO obligations. Most will reject language permitting use in performance or disciplinary proceedings. Decide your position on this before the meeting. Do not discover it at the table.

The vendor's data processor agreement. Your scheduling software vendor processes employee personal data on your behalf, making them a sub-processor under GDPR. The OR will ask whether a DPA is in place. Having the signed DPA ready removes a standard objection and demonstrates that the vendor relationship has been properly structured.

---

Structuring the Instemming Request: The Meeting That Actually Works

Submit the instemmingsverzoek in writing at least two weeks before the scheduled meeting. The OR has six weeks to respond by law, but giving them time to prepare signals respect and usually compresses the actual response time. A written request also forces you to articulate the purpose clearly, which is good practice regardless.

Lead with the operational problem you are solving, not with the software's features. Open with something like: "We are currently managing shift changes through WhatsApp groups, which means roster adjustments are unrecorded, toeslag obligations are being missed, and employees have no reliable way to verify their own schedules." This gives the OR a concrete picture of the problem. It also repositions the software as a solution to a workforce problem, not a management control tool.

Offer a joint evaluation period. Propose a three-month review clause in the instemming agreement, where the OR reviews actual data usage against the commitments made and can raise concerns formally before the agreement becomes permanent. This is the single most effective concession in the opening package. It converts a permanent decision into a reversible pilot in the OR's mental model, which substantially lowers their threshold for initial consent.

Bring a named OR liaison on your team. One person who serves as the single point of contact for all follow-up questions between meetings. Without this, objections accumulate between sessions instead of being addressed, and what could be resolved with a 15-minute call turns into an agenda item at the next monthly meeting.

---

Negotiating the Instemming Agreement: What to Concede and What to Hold

Some OR demands are reasonable and operationally livable. Others create constraints that make the system effectively unusable.

Concede these without much resistance: individual employees can download their own complete scheduling history on request; there is an audit log showing who accessed which employee's data and when; the data retention policy is reviewed annually with OR input. None of these impair the system's operational value. All of them are good practice anyway.

Hold on individual-level OR access. An OR member having visibility into individual employee schedules and attendance records to perform their representative role creates its own privacy problem: it puts employee personal data in the hands of people who are also colleagues. Aggregate, anonymised workforce analytics are appropriate and useful for the OR's collective representation function. Individual-level data is not, and most ORs with sound legal advice will understand this distinction once it is explained clearly.

The dispute-use clause is the actual negotiation. Take it seriously and prepare your position in advance. The workable distinction — which I have seen agreed in most successful instemming processes — is this: scheduling data can be used to verify compliance with CAO and statutory working hours obligations; it cannot be used as primary evidence in performance assessments or disciplinary proceedings unless the employee has raised a specific factual dispute about the record itself. This protects employees from data being weaponised while preserving the employer's ability to demonstrate CAO compliance in a Labour Inspectorate audit.

If the OR asks for a veto over auto-scheduling decisions affecting individual employees, this is usually about transparency rather than control. Offer a transparency mechanism: employees receive the system's stated reason for a shift assignment, and there is a formal objection channel. This addresses the underlying concern without creating an operational approval loop for every auto-generated roster.

---

The Parallel Track: CAO Compliance as an OR Argument, Not Just a Risk

Here is the framing shift that most HR managers miss, and it is the difference between an OR that is suspicious and one that is actively supportive.

Works councils care about CAO enforcement. An OR with FNV delegates is often more concerned about systematic toeslag under-payment and rest-period violations than about data surveillance. These are members who have personally chased retroactive corrections for colleagues who were consistently scheduled closing-then-opening shifts. The 11-hour ATW rest requirement is a well-documented compliance failure across retail and hospitality, and OR members in those sectors know it.

Frame the scheduling system's compliance features as tools that protect employees. Automatic detection of rest-period gaps below the ATW minimum. Toeslag calculation at the point of scheduling, not after payroll processing when the error is already baked in. Audit trails that employees can access directly to verify their own entitlements.

Bring a specific example from your own data. This is uncomfortable but highly effective. Something like: "We reviewed last quarter's rosters and found fourteen instances where a closing shift ending at 22:00 was followed by an opening shift starting at 06:00. That is eight hours between shifts, well below the ATW minimum of eleven. This system would have flagged those at the planning stage before they were published." A concrete number from your own operation is worth more than any general claim about the software's capabilities.

This argument resonates particularly strongly in care and retail, where oproepkracht scheduling creates the kind of compliance complexity that WAB-proof workforce planning is specifically designed to address, and where OR members have direct experience of violations that were caught late and corrected badly.

When describing what a compliant scheduling tool should actually do, it is worth being specific about what you expect from the system. Something like Soon's auto-scheduler — which applies rest-period constraints during shift generation rather than as a post-hoc check, and allows employees to view their own complete scheduling history directly — gives you concrete examples to cite when explaining to the OR how the design addresses their concerns. The key is specificity: "employees can download their own shift history" is a stronger OR argument than "the system is employee-friendly."

---

What Goes Wrong Even After You Get Consent

Getting the instemming is not the end of the process. It is the beginning of an ongoing obligation.

Scope creep is the most common post-consent breach. The system was consented for workforce scheduling and time registration. Someone in HR then starts using the absence pattern data for a predictive attendance model, or operations leadership begins scoring site managers based on individual employees' punctuality records. Neither of these uses was in the instemming agreement. When an OR member discovers this — usually through an employee complaint — the trust built over the consent process collapses immediately.

Build a clause into your vendor contract requiring notification of material feature changes. A significant product update adding new monitoring capabilities, absence prediction, or performance scoring may independently trigger a new Art. 27 obligation. You cannot manage this if you do not know the feature was added.

Management access scope tends to expand organically. A new regional manager joins and gets access to individual employee schedules across multiple sites. That access may exceed the originally consented scope. Treat access provisioning as a compliance activity, not just an IT task, and have someone in HR reviewing it annually against the instemming agreement.

Finally, keep the OR informed proactively. A brief annual update showing data usage against the commitments made takes thirty minutes to prepare and thirty minutes to present. It prevents the scenario where the OR learns about a change from an employee complaint rather than from you, which is how otherwise manageable situations become formal disputes. The OR that consented to your system is an ally. Treat them accordingly.