Building productivity categories that fit each team

Every productivity figure rests on a quiet assumption: that someone has decided which applications and websites count as productive. Get that decision right and productivity reports are a fair reflection of how time is spent. Get it wrong and good people look unproductive, distractions look like work, and the whole team learns to ignore the numbers.

The most common mistake is treating classification as a one-time, company-wide setting. Work does not look the same across teams, so the rules should not either.

Start with categories, not individual apps

Classifying hundreds of applications and websites one by one is tedious and hard to maintain. Group them into categories first: Development, Design, Communication, Office and documents, Meetings, Browsing, Social media, Entertainment and so on. Then decide whether each category is productive, neutral or unproductive. New apps only need to be placed in a category, and the classification follows.

• Productive: tools that directly produce the team's work, such as a code editor for engineers or a design tool for designers.
• Neutral: necessary but supporting activity, such as email, chat, calendars and general browsing.
• Unproductive: activity unrelated to work for that team, such as entertainment sites.

Accept that teams differ

A video platform is a distraction for a finance team and a core tool for a marketing team producing video content. A spreadsheet is the main workspace for an analyst and an occasional tool for an engineer. Social media is entertainment for most people and the job for a social media manager. A single company-wide rule set cannot represent all of these accurately.

This is why per-team overrides matter. Keep a sensible company-wide default, then let each team adjust the handful of categories or apps where their work genuinely differs. In BeeWorkforce, team-level application policies override the company rules for just that team, so marketing can count a video site as productive without changing it for everyone else.

Involve the team in the rules

The people doing the work know best which tools matter. Before finalising a team's rules, share the draft with a few team members and ask: does this look like your working day? Which tools are missing? Which ones are classified wrongly? This takes half an hour and dramatically increases trust in the resulting numbers.

If a team does not recognise itself in its productivity report, the report is wrong, not the team.

A worked example

Imagine a company with three teams: engineering, marketing and customer support. The company-wide defaults might look like this: Development and Design productive; Office and documents productive; Communication and Meetings neutral; Browsing neutral; Social media and Entertainment unproductive.

For engineering, those defaults fit well. Code editors, terminals and issue trackers are productive, chat is neutral, and entertainment is unproductive.

Marketing needs two overrides. Social media is part of the job, so it becomes productive for this team only, and the video platform the team publishes to becomes productive too. Without these changes, the people doing exactly what they are paid to do would show as the least productive team in the company.

Customer support needs a different adjustment. The help desk tool and the phone system are where the work happens, so they should be productive, even if they are classified as neutral communication tools by default. Long periods on calls may also show as idle time if they happen away from the keyboard, so the team's manager should read activity figures with that in mind and consider manual time entries for offline work.

Three teams, a handful of overrides, and productivity figures that each team recognises as fair. That is usually all it takes.

Handle websites carefully

Browsers are where classification gets tricky. The browser itself is just a container; what matters is the site. Classify by domain wherever possible, and use more specific URL rules only when a single domain hosts both work and non-work content. Keep these rules few and well documented, because they are the ones most likely to surprise people.

Tips for website rules

• Classify the company's own tools and intranet as productive or neutral by default.
• Classify documentation and reference sites as neutral rather than unproductive.
• Be careful with news and social sites that some roles legitimately use.
• Review the list of unclassified sites every month and place the frequent ones.

Watch for signs the rules are off

Productivity numbers that look surprising are often a classification problem in disguise. Signs to look for include a whole team with unusually low productivity, a person whose productivity dropped right after a tool change, or large amounts of time in unclassified apps. Before drawing conclusions about people, check the rules.

Explain the rules to the people affected

Once a team's rules are settled, publish them where the team can see them: which categories count as productive, which as neutral, and why. People are far more comfortable with productivity figures when they can see exactly how they are calculated, and they are more likely to flag a tool that has been missed.

Review regularly

Teams adopt new tools, retire old ones and change how they work. Put a quarterly review in the calendar: look at the most-used apps and sites per team, check their classification, and fix anything that no longer fits. The effort is small and keeps the numbers credible.

Good classification is less about perfect rules and more about rules that each team recognises as fair. Start with categories, allow team-level differences, involve the people affected and review regularly. The productivity figures that come out the other end will be ones your team can actually use.