Talking to the works council about analytics: a preparation

Anyone in Germany who wants to introduce conversation analytics, quality management or AI assistance in a contact centre will meet the works council. That is not an obstacle but a designed part of the process.

Well prepared, it becomes a conversation that makes the rollout more stable.

This post shows which questions typically come up and which documents help. It is not employment law advice. Involve your legal team and your data protection officer early.

#Why the works council has a say

Under Section 87(1) No. 6 of the Works Constitution Act (BetrVG), the works council co-determines "the introduction and use of technical systems designed to monitor the conduct or performance of employees".

The wording says "designed to". The Federal Labour Court has long read this broadly: it is enough for a system to be objectively capable of monitoring conduct or performance. Intent does not matter.

For a contact centre, this means almost any analysis that can attribute conversations to individuals is covered. If no agreement is reached, the conciliation board decides under Section 87(2).

#The right moment

The most common mistake is a late meeting. If the works council only hears about the project once contracts are signed and training is planned, there is little room left to shape it. The conversation turns into a defence.

An early meeting during planning works better, with open questions rather than finished answers. Many concerns, such as analysing only at team level, can be met without extra effort if they are known in time.

#The questions that will come

A works council's questions are rarely surprising. They fall into six groups, and you can prepare an answer for each in advance.

• Purpose: what is the analysis for? Finding knowledge gaps, improving processes, assuring quality?
• Data: which data is created? Recordings, transcripts, topics, sentiment, metrics?
• Attribution: are results attributed to individual employees or only to teams?
• Access: who sees which analysis, and who can grant permissions?
• Retention: how long are recordings and results stored?
• Changes: what happens when new analyses are added later?

#Configuration, not declarations of intent

A sentence like "we will not use this to monitor performance" convinces few people. A configuration that does not allow it is convincing. Univerx can be configured so that recording, analysis and role permissions follow the rules you have agreed.

So show the settings themselves, not just slides. The table below maps typical questions to the places where the answer becomes visible in the system.

#Describe roles clearly

Many misunderstandings arise because "management" is treated as one role. In practice there are several, with different needs. Describe each role by what it sees and what it does not.

• Agents see their own conversations, their own summaries and Assist suggestions.
• Team leads see the topics and metrics of their team, with details only within the agreed scope.
• Quality management assesses conversations against an agreed form, using samples rather than full analysis.
• Administrators grant permissions but see no content they do not need.

#Present AI analysis separately

For AI-supported analysis, such as sentiment or automatic quality scoring, the questions get more specific. How is a result produced? Can it be wrong? Who decides on consequences?

Disclose which features feed into a result, and show what it looks like on a sample conversation. A concrete example answers more questions than any description.

A clear stance helps: AI results are pointers, not verdicts. Any assessment that may have consequences for a person is made by a human. The Trust Center sets out these principles under Responsible AI.

#Documents that carry the conversation

1. Purpose statement. One page: what should be achieved, and what explicitly not?
2. Data overview. Which data is created, where it is held, how long it stays.
3. Role matrix. Every role with its views and permissions.
4. Screen views. The views exactly as each role sees them.
5. Data protection impact assessment. Usually indicated for conversation analytics; see DPIA.
6. Change procedure. How new analyses are requested and agreed.

The result usually becomes a works agreement. Under Article 88 GDPR, such an agreement can also contain more specific rules for processing employee data.

#Use the pilot as a demonstration

A pilot with one team and one channel is also a good frame for the works council. It shows real views instead of assumptions and can be limited in time and scope.

How to set one up is described in A pilot with one team and one channel.

How topics rather than single numbers change a team lead's work is shown in Team leads see topics, not just numbers.