Equipment and Works Councils: A Practical Guide for HR Teams Consulting Before They Buy

By [Author Name] · [Date] · [X] min read · [Table of Contents]

TL;DR

• Works council consultation on equipment is the process of involving an employee representative body before changing how devices are issued, monitored or recovered.
• If you've no representative body in any market, this doesn't apply, and that's most companies under a certain size.
• It does three jobs: it surfaces objections while they're still cheap, it builds a record of what was agreed, and it stops a rollout being paused halfway.
• What triggers it, when, and with what effect differs by jurisdiction and by the body, so that part needs local advice every time.
• Choose what to raise based on whether the change affects monitoring or personal use, not on how large the project is.
• Done right, the consultation happens before procurement rather than after deployment.

Three weeks to go-live. A device management rollout across five countries. The platform is chosen, the licences are bought, the pilot went well. Then somebody in the German entity asks whether the works council has seen it, and the answer is that nobody raised it because the project was framed as an IT upgrade rather than as a change to anything affecting employees.

These aren't edge cases. A company that grew into Europe through 3 acquisitions inherited 2 representative bodies it has never dealt with directly. Another has one council in one market and treats it as that market's problem, so the central IT team plans without knowing it exists. A third consulted properly on a tracking feature and then enabled a second feature nine months later in a routine platform update, which nobody thought to mention.

Recommended Tools

Best tools for HR Operations

B BambooHR HR management system R Rippling HR & IT automation W Workday Enterprise HRIS

View all recommended tools

The real issue isn't whether you need to consult. It's that equipment decisions are made by people who don't think of themselves as changing anything about employment, and the consultation question arrives after the money is spent.

When You Don't Actually Need to Think About This

Stage one: it genuinely doesn't apply. No representative body in any market you operate in means no consultation obligation of this kind, and that covers a large share of companies under a few hundred people. Knowing that for certain is worth one question to somebody local rather than an assumption either way.

Stage two: friction appears. You have a body in one market, the relationship is handled by a local HR lead, and central projects are planned without anybody checking. Nothing has gone wrong yet and the first thing that does will be a surprise to the people who planned it.

Stage three: it becomes a liability. A rollout is paused after deployment, or a monitoring feature has to be switched off in one country after it was enabled everywhere, which is both more expensive and considerably more visible than raising it early would have been.

Stage four: the edge case. A change that was fine at consultation becomes something else through a vendor update. Platform capabilities expand without anybody choosing them, and a feature nobody discussed appears in a release note that goes to an IT inbox.

What HR Teams Actually Need to Know Before a Rollout

> "Does this change anything about monitoring?" > That's the question that decides most of it. > Anything that observes, logs or reports on what a person does is in a different category from anything that merely manages a machine.

> "When should we raise it?" > Before procurement, not before deployment. > A body consulted after the contract is signed is being asked to approve a decision, which is a worse conversation than being asked about a proposal.

> "What exactly are we proposing?" > Write it in plain language without product names. > Most difficulty here comes from describing a capability vaguely, which invites the broadest possible interpretation of what it might do.

> "Who owns the relationship?" > A named person locally, who should be in the project from the start. > Central teams that treat this as a compliance step at the end lose the benefit of having somebody who knows how the body actually works.

> "What happens if they object?" > Depends entirely on the jurisdiction and the body, so ask before you need to know. > Finding out what an objection means while one is live is the most expensive possible time to learn it.

There's a sixth question that comes up later and should be settled first. What happens when the platform changes? Vendor updates add capabilities nobody selected, and a consultation that described what the system did in March may not describe what it does in November.

The Three Categories of Equipment Change

Pure logistics. What it is: how devices are bought, shipped, stored and recovered. When it rarely touches consultation: where nothing about the employee's use of the device changes. A new supplier or a different courier is an internal procurement matter. When it does: where it introduces something about the person, such as collection from a home address, or a requirement to be present for a delivery. Then it is no longer purely logistical.

Management and configuration. What it is: enrolment, patching, remote wipe, standard builds, encryption. When it rarely touches consultation: where capability is limited to the machine and the configuration. Keeping a laptop patched isn't an observation of anybody. When it does: where the same platform carries capability that observes. The distinction readers care about isn't what you've enabled but what the system is capable of, and that's frequently a surprise to the project team.

Monitoring and location. What it is: activity logging, screen capture, location tracking, usage reporting, anything producing data about a person. When it rarely touches consultation: essentially never. Assume this category requires a conversation in any market where a representative body exists at all, whatever the change looks like from the inside. When it does: always, and earlier than feels necessary. This is the category where retrofitting consultation after deployment causes the most damage.

The middle category is the one that catches people, because a project team plans a management rollout and the platform happens to include the third category as an option.

How to Choose What to Raise: Five Questions

Does it produce data about a person? This is the cleanest test available. If the change generates a record of what somebody did, where they were, or how long they worked, treat it as consultable and start early. If it generates a record about a machine, you've more latitude.

Does it change what the person may do? A rule about personal use, installing software, or taking a device somewhere is a change to the terms of their working life rather than a technical setting, and it reads that way regardless of how it was framed internally.

What's the platform capable of? Not what you've switched on. Read the feature list properly before the conversation, because being asked about a capability you didn't know existed is the worst way to discover it.

Who has the relationship? Find out who locally deals with the body and bring them into the project at planning rather than presenting them with a rollout to approve. They will know in an hour what the central team would take a month to work out.

What does the timeline actually allow? Consultation takes time that varies by market and by body. Build it into the plan as a dependency rather than as a parallel activity, because treating it as parallel is how go-live dates become the pressure that makes the conversation go badly.

Six Platforms Worth Knowing

RemoAsset Best for: logistics that stay in the first category, where procurement and retrieval change without anything about monitoring. Why companies choose it: procurement and retrieval across 80+ countries with devices tracked through issue and return, which is an asset record rather than an activity record, and that distinction is the whole reason it usually sits in the easiest category. Pricing is published, from $1,499 a year on the Subscription tier for companies with 50 to 5,000+ employees, including a 60 per cent reduction on retrieval charges. It's our own product, so weigh that accordingly. Where it struggles: no network discovery, so it can't tell you what's actually on your network, and no software licence management. Only the Subscription tier publishes a figure, with pay-as-you-go quoted. It isn't a management platform and has no monitoring capability, which is a limitation in general and genuinely useful here. It won't tell you whether consultation is required anywhere.

Workwize Best for: warehousing and stock-holding changes that stay logistical. Why companies choose it: its own warehouses, which keeps the change on your side of the relationship. Where it struggles: no published rate card, and the figures on its pricing page are savings claims rather than prices. The live domain is goworkwize.com.

Firstbase Best for: supply-side changes with no employee-facing component. Why companies choose it: strong supply chain and a clean subscription shape. Where it struggles: publishes nothing on price, and retrieval is the weaker half.

GroWrk Best for: companies wanting a service shaped around market-by-market differences. Why companies choose it: flexible arrangement rather than one fixed package, which suits a business with different obligations in different places. Where it struggles: no rate card, and its pricing page runs a competitor cost estimator whose figures are its own estimates.

allwhere Best for: outsourcing logistics without changing anything employee-facing. Why companies choose it: managed service, minimal internal lift. Where it struggles: publishes nothing, so comparison requires a conversation.

Deel IT Best for: companies already employing through Deel in the markets concerned. Why companies choose it: hardware and employment in one relationship, which can simplify who holds the local conversation. Where it struggles: weaker standalone, and no published pricing.

The Decision Table: What to Raise and When

The second row is where most projects sit and where most of them get this wrong.

The reason that row is difficult is worth naming. A device management rollout is genuinely framed as an infrastructure project by the people running it, and they are not being careless: enrolment, patching and encryption really are machine-level concerns with no employee-facing component at all. The problem is that the platform delivering those three things usually also delivers the third category in the table, as an option nobody selected and nobody mentioned, and the question a representative body asks is about what the system can do rather than about what the project intended. That gap between intent and capability is where almost every difficult conversation in this area starts.

A Sequence for a Multi-Market Rollout

The advice so far is to raise it before procurement. Here is what that looks like laid out, for a device management rollout across several countries where at least one has a representative body.

The verification row is the one that gets dropped, and it is the one that makes everything above it real. An agreement that nobody checks against the deployed configuration is an intention, and the gap between the two is usually accidental rather than deliberate: somebody configures from the vendor's default template rather than from the agreed specification, and a capability arrives switched on because that is how it ships.

Check it once, at deployment, against the written record. Fifteen minutes. If it matches, you have something defensible for years; if it does not, you have found it at the only point where fixing it costs nothing.

The last row runs forever, which is the only row with no end date. That is deliberate, because the thing being guarded against is drift rather than a decision.

Raise It Before Procurement, Not Before Deployment

This is the single most useful thing on the page and it costs nothing to get right.

The instinct is to consult once the plan is firm, because a vague proposal feels like a waste of everybody's time. That instinct produces the worst version of the conversation. By the time the platform is chosen and the contract is signed, you aren't presenting a proposal, you're presenting a decision and asking for agreement, and any objection now has a cost attached that everybody in the room can see.

Raise it while the choice is still open. A proposal that says we are considering how to manage devices across these markets, here is roughly what it would do, here is what we are trying to achieve, invites a different conversation. Objections at that stage change the specification, which is free. Objections after deployment change the deployment, which is not.

There's a second benefit that teams discover afterwards. Early consultation frequently narrows the scope in ways the project team is happy with, because a body asking what a capability is for will sometimes establish that nobody actually wants it, and switching it off at design time is cheaper than configuring it and then defending it.

The practical change is to the project plan rather than to anything else. Put the consultation as a dependency ahead of procurement rather than a workstream alongside build, and the whole problem reduces to a scheduling decision made once.

If There Is an Objection

The article has said to find out what an objection means before you need to know. Worth going further, because the practical handling is largely jurisdiction-independent even though the legal effect is not.

Ask what, exactly. What is actually being objected to is frequently much narrower than the objection first appears. A body raising concerns about a management platform is usually concerned about one capability rather than the whole proposal, and asking which part specifically converts a blocked project into a scoping conversation. Teams that treat an objection as a verdict rather than as a question lose weeks.

Then establish whether the objection is to the capability or to the absence of a safeguard. Those have completely different answers. Objections to capability mean the feature goes or the project changes; objections to safeguards mean you are being asked who can see the data, how long it is kept, and what it will not be used for, and those are usually answerable without changing the specification at all.

Expect the secondary use question. It is the most common concern and the one project teams are least prepared for. A capability introduced for security reasons can in principle produce data useful for performance management, and the question of whether it will be used that way is reasonable, foreseeable and should have an answer before it is asked. A clear undertaking that it will not be, recorded, settles more objections than any technical argument.

What not to do is escalate to the legal position early. Whether an objection has binding effect is a question for local advice, and reaching for that answer in the first conversation changes the nature of the relationship in a way that costs more on the next project than it saves on this one.

I've seen the same proposal accepted in one market and rejected in another, with the difference being entirely in how precisely the negative commitments were written.

Describe the Capability, Not the Product

How you write the proposal matters more than people expect, and the common mistake is to describe a product rather than a capability.

Naming a platform invites everybody to read its marketing material, which describes everything it can possibly do rather than what you intend to use. That's a conversation about the vendor's feature list rather than about your proposal, and it is very hard to recover once it starts.

Write what will happen instead. Devices will be enrolled so they can be kept updated and encrypted. If a device is lost, it can be erased remotely. No activity, location or usage data will be collected. Those three sentences describe a capability set precisely, and every one of them is checkable against a deployed configuration, which is what makes them worth writing that way.

Then be exact about the negative statements, because they're the ones that carry weight. Saying no monitoring is planned is weaker than saying the monitoring features won't be enabled, and both are weaker than stating which specific capabilities are off and will remain off without a further conversation. The specificity is doing the work.

And don't promise what you can't control. A platform may gain capabilities through an update, so a commitment that the system will never be able to do something is a commitment you may have to break. A commitment that you won't enable something without returning to the conversation is one you can keep, and it is the one worth making.

The Acquisition Case

This has been mentioned twice and deserves its own treatment, because it is the most common way a company discovers it has an obligation it did not know about.

Acquisitions bring bodies. An acquisition brings employees, entities and sometimes a representative body, and none of those appear anywhere in an IT integration plan. The plan covers systems, licences, device standards and a timeline for bringing the acquired fleet onto the company build. That last item is a device management change affecting every acquired employee, which is exactly the category this page is about, and it is scheduled for week six.

Ask in the first week. One question to the acquired entity's HR lead: is there a representative body, and what has it been consulted on before. The answer takes a minute to give and it determines whether week six is realistic. Discovering it in week five produces either a delay or a decision somebody will regret.

There is a subtler version worth knowing about. The acquired company may have made commitments of its own, to its own body, about what its systems would and would not do, and bringing those employees onto your platform may breach an undertaking nobody in your company has read. Asking what was previously agreed is as important as asking whether a body exists, and it is the question nobody thinks to ask.

Treat it separately. The acquired fleet is a separate consultation rather than an extension of yours, because an agreement reached with one body does not carry across to another. Different employees, different body, possibly different market, and an agreement reached with one body does not carry across to another. The shortcut of assuming the existing agreement covers the new population is tempting and wrong.

And put the question on the integration checklist permanently. This recurs with every acquisition and the checklist is the only thing that remembers.

The Vendor Update Problem

This is the part almost nobody plans for and it is how a clean consultation goes stale.

Picture the sequence. You consult in March on a platform that does management and not monitoring, and everybody is satisfied with where it lands. In September the vendor ships an update adding a usage reporting dashboard, enabled by default for administrators. Nobody chose that, nobody announced it internally, and the release note went to an IT distribution list. The system now does something the consultation said it would not.

The fix is a diary entry. A quarterly review of release notes by somebody who knows what was agreed, which is the only control that works here. That's a twenty-minute job and it is the only control that works, because the alternative is finding out when somebody else notices. Make it a named responsibility rather than a shared intention.

Then switch it off. What to do when something appears is a judgement, and the honest default is to disable it first and decide afterwards. A capability switched off is a capability you can discuss calmly. One that has been running for two months while nobody mentioned it is a different conversation entirely, and the gap between those two is the whole reason the review exists.

Keep a short record of what was agreed, in terms of capabilities rather than settings. Settings change names between versions, and a record that says location services disabled won't survive a vendor renaming the feature, while one that says no location data will be collected survives anything.

Recording What Was Agreed

The article has twice said to keep a record in terms of capabilities. Here is the format, because this is the artefact that still matters in three years when everybody involved has moved on.

One page per market, which is short enough that somebody will actually read it three years from now when the original participants have all moved on. What was proposed, in plain capability language. What was agreed. Which capabilities are explicitly off and the undertaking not to enable them without returning. Who was involved on both sides, and the date. Nothing else at all, because a longer document is one nobody reads when it matters.

Capabilities, not settings. Write it that way because settings get renamed between versions and capabilities do not. A record saying location services disabled dies the moment a vendor calls the feature something else, while a record saying no location data will be collected survives every rename, every version and every platform migration. That distinction is the single most useful thing about how this document is written.

Store it where the next person will find it. Not in the project folder, which gets archived when the project closes, and not in an individual's mail. The relationship is ongoing and the record needs to outlive the rollout, which usually means wherever your HR documentation for that market lives rather than wherever IT keeps project artefacts.

Then reference it rather than rewriting it. The next proposal in that market should start by saying what was agreed before and what is changing, which is both a faster conversation and a demonstration that the previous agreement was taken seriously. Bodies notice that, and it is the cheapest goodwill available in this whole area.

Review it when the platform changes substantially. Not every update, but a migration to a different product is a new proposal rather than a continuation, and treating it as a continuation is how a company ends up with an agreement describing a system it no longer runs.

Who Should Own This Centrally

A structural point, because the failure is almost always organisational rather than legal.

Equipment projects are run by IT or by procurement. Works council relationships are held by local HR. Those two groups have no routine reason to talk to each other, and in a company where the project is planned centrally and the relationship sits in one market, the connection depends entirely on somebody remembering.

Name one person. Centrally, owning the question for every project that touches a device standard anywhere in the business, so that the asking of it never depends on whoever happens to remember. Not the relationship, which stays local, but the question of whether a given change needs raising anywhere. Their job is to ask it early, every time, and to know which markets have a body at all. That's a small role and it removes the whole failure mode.

Give them a list. Which markets have a representative body, who the local contact is, and roughly how long consultation has taken there before. Three columns, maintained once a year, and it answers in thirty seconds the question that otherwise triggers a week of internal archaeology.

The acquisition case needs a specific trigger. A company acquired with employees in a new market may come with a body nobody has mentioned, and the integration checklist should ask directly rather than waiting for it to surface. That's a question for the first week, not the first incident.

Where Jurisdiction Decides Everything

This is the part that is not a process question and cannot be answered here.

Ask locally, every time. What a representative body is, when it must be involved, what the involvement consists of, what effect an objection has, and what happens if a change proceeds without it all differ by jurisdiction and by the specific body. There is no general rule to apply, and a policy written in one market and used in another is the most likely source of a serious error in this whole area. Take local advice, in each market, before the change rather than after it.

The same applies to anything about monitoring, personal use of devices, or data generated about employees. Those sit alongside other obligations that vary by place, and the answer in one country tells you nothing reliable about the next.

What is portable is the practical discipline, and it turns out to be most of the value in any case. Raise it before procurement. Describe capabilities rather than products. State which capabilities will be off and commit to returning before enabling them. Review vendor updates quarterly against whatever was agreed, by somebody who actually knows what that was. Keep a three-column list of which markets have a body and who holds the relationship. None of that needs advice, and all of it is what determines whether the conversation goes well.

So the division is clean, and it is worth stating explicitly because teams tend to treat the whole subject as a legal question and therefore as somebody else's problem entirely. The timing, the framing and the record are entirely within your control and need nobody's permission. The obligation itself is a question for somebody local, every time.

What This Looks Like When It Works

Worth describing the finished state, because the page so far is a list of controls rather than a picture.

A project starts. The central owner checks a three-column list, sees that two of the five markets have a representative body, and emails the two local HR leads in week one. They come back with a contact and a rough timeline, and that timeline goes into the plan as a dependency ahead of procurement rather than as a parallel task.

The proposal is three paragraphs of plain capability language with the negatives stated precisely. One body asks two questions about secondary use and gets a clear written undertaking. The other adjusts nothing. Both agreements get recorded as one page each, in capability terms, stored with the HR documentation for that market rather than in the project folder.

Procurement happens against the agreed specification. At deployment somebody spends fifteen minutes checking the live configuration against the record, finds one capability switched on by vendor default, and turns it off before anybody notices. Every quarter after that, release notes get read against the record by the same person.

Nothing about this is difficult and none of it took long. The whole of it is a list, a named owner, a sequencing decision and an hour a quarter, and the reason it is worth writing down is that each individual piece is obvious while the combination almost never happens by itself.

The Cost of Getting This Wrong

The direct cost is a delayed rollout, and that is genuinely annoying rather than serious. A project paused for six weeks while a conversation happens is a schedule problem.

What is expensive is a rollback. Switching off a capability in one market after it has been running everywhere means a configuration split you now maintain indefinitely, a visible reversal that gets discussed, and a harder conversation the next time you propose anything. I've watched a company spend considerably more on managing a two-country configuration difference across 340 machines for 19 months than the entire consultation would have cost, and the difference persisted for years because nobody wanted to reopen it.

The second cost compounds. It lands on the relationship itself. A body that was consulted late once will reasonably scrutinise the next proposal more closely, which makes every subsequent project slower. That is a rational response to being presented with a decision rather than a proposal, and it is self-inflicted.

Third is the quiet one. Where nobody owns the question, it does not get asked, and the company has no idea whether it has a problem until something surfaces. The absence of a list is the real exposure rather than any particular project.

So the question worth asking is not whether this rollout needs consultation. It is whether anybody in the company could tell you, today, which markets have a representative body and who holds each relationship.

When You're Ready to Move Beyond Asking Around

You will know when a project is late in planning and somebody asks the question for the first time, which is the pattern this page exists to interrupt.

A list and an owner. That is what replaces it. Three columns of markets, contacts and typical timelines, one person centrally who asks the question at planning for every project, and a quarterly review of vendor release notes against what was agreed. That is an afternoon to set up and about an hour a quarter to maintain.

RemoAsset is our own product, so weigh this accordingly. The reason it is relevant is narrow and slightly unusual: because it is a procurement and retrieval platform with no monitoring capability at all, changes to it generally stay in the easiest category, and that absence of capability is a feature in this specific context rather than the limitation it is elsewhere. It records devices rather than people.

If you cannot currently name which of your markets have a representative body, start there. Everything else on this page depends on it.

Frequently Asked Questions

A device record that tracks hardware, not people.