You pay for tools the team doesn't use: here's how to introduce the system before the tools

Table of contents

INTRODUCTION

You pay for tools that the team does not use — and with that you pay for chaos: double work, emails, messages and meetings that serve only to "catch" the status. And then you wonder: how is it possible that we bought a "better" tool, and the team still goes back to email, excel and messages? The problem is usually not in the tool. The problem is that you are trying to "glue" the tool to the old way of working.
In practice, I see this all the time: a company introduces a new tool (Planner, Asana, Teams, CRM…), gives a short presentation and expects the team's behavior to change on its own. They won't. Without clear context, rules, and responsibilities, the tool remains an add-on — not a solution.

In this text I explain:

  • Why the team ignores the tool
  • What happens when there's no system (and why everyone goes back to email)
  • How to introduce a way of working that makes the tool "work for you"
  • A checklist of steps you can apply immediately

What actually happens when you introduce a tool and the team ignores it

When there is no clear context, people don't know:

  • Why we introduce a tool (which solves the problem)
  • What is changing in the way we work (what stops, what starts)
  • Who is responsible for what (ownership of tasks, deadlines, information)
  • Where is the truth (in an email, in a tool, in messages, in a spreadsheet?)

In that vacuum, the team does the safest thing: it goes back to the way it was. Not because they are "lazy" or "resistant", but because the old way of working is familiar and predictable.

Consequence 1: No system = back to the old

If the team does not have a defined way of working, the tool cannot defeat the habit.

The most common scenario:

  1. The task opens in the tool.
  2. The comment is written in the chat.
  3. The document is sent by email.
  4. The status is asked at the meeting.

And then everyone says, "This tool doesn't work." No — the tool works. The system does not exist.

Email is "safer" because:

  • everyone knows it
  • it acts as proof that something has been sent
  • it's easy to shift responsibility ("I sent you")

But email is not a work system. Mail is a channel. When a channel becomes a system, you get chaos.

Consequence 2: The result is duplicated work and confusion

When there is no centralized way of working, the team falls into three parallel realities:

  • He ignores the tool because he doesn't see a clear benefit
  • It goes back to the email because it is familiar
  • It does double work because no one is sure where what goes

That quickly turns into:

  • missed deadlines
  • "lost" tasks
  • shifting blame
  • more meetings to clarify what should have been clear

And of course: you pay for a tool you don't use.

The mistake most companies make: "We need another tool"

This is the most expensive sentence in digital transformation.

Adding new tools without changing the mode of operation:

  • increases confusion
  • increases the team's cognitive load
  • creates resistance ("something new again")
  • breaks focus

The solution is not a new tool. The solution is a clear way of working.

Solution: First the system, then the tool

The tool should support a clearly defined process. Only then does it begin to bring results.

Here's what "system before tools" means in practice.

1) Define one source of truth

Answer the question: Where is the business conducted? If the answer is "everywhere", then the answer is "nowhere".

Example rule:

  • Tasks and deadlines are in the tool (there is no "I will send you by email")
  • Documents are in a shared space (SharePoint/Drive), not in attachments
  • The status is not asked in the meeting if it is updated in the tool

2) Introduce minimum rules of use (not 20 pages of procedures)

The team doesn't need a manual. He needs 5 to 7 clear rules.

Examples:

  • Each task has an owner (one person)
  • Each task has a deadline or clearly "no deadline"
  • Communication about the task goes in the comments of the task, not in the chat
  • "Done" means: delivered + documented + process owner notified

3) Separate channels: chat is not a task manager

Chat is great for quick coordination. But if tasks are negotiated in chat, they disappear.

The rule that works:

  • Agreement in chat → task in the tool within 5 minutes

4) Assign roles and responsibilities

Without ownership, there is no adoption.

Roles that are often missing:

  • Process Owner (what is standard)
  • Tool owner (how to use, templates, rules)
  • Team Leader (Consistency, Follow-up)

5) Create an "onboarding" for the tool (yes, also for the existing team)

People don't adopt a tool through one presentation.

An effective mini-onboarding includes:

  • 30 minutes: Why we introduce the tool (what stops being done)
  • 30 minutes: demo on a real project (not an "example")
  • 7 days: rule of consistency (everything goes through the tool)
  • 14 days: a short retrospective (what doesn't work, what needs to be adjusted)

6 practical tricks to make the team actually use the tool

  1. Remove duplicates: if the task is in the tool, it is not sent by email.
  2. Create templates: project, onboarding, monthly report, so that the team does not start from scratch.
  3. Enter "definition of done": which means completed, not to return 5 times.
  4. Measure adoption: e.g. % of tasks with owner and deadline.
  5. Connect the tool to the team's rhythm: weekly overview in the tool, not in PowerPoint.
  6. Reward consistency: praise the behavior, not just the result.

The most common mistakes (and how to avoid them)

  • Mistake 1: "Everyone will manage" Solution: minimal rules + short training.
  • Mistake 2: Too many features from day one Solution: start with the basics (tasks, deadlines, owners), then expand.
  • Mistake 3: Nobody owns the tool Solution: Appoint a person who maintains the templates and rules.
  • Mistake 4: The tool is used "when we remember" Solution: introduce a rhythm (weekly review, daily update, retrospective).

Mini case study: "We bought a tool, but chaos remains"

One team I worked with introduced a task management tool because they were "losing things in email". After 6 weeks, the situation was worse: the tasks were both in the tool and in the email, and the status was still checked in meetings.

What we did:

  1. We have defined one source of truth: tasks and deadlines are exclusively in the tool.
  2. We have introduced 6 rules of use (one page, not a 20 page document).
  3. We have created 3 templates: onboarding, standard project, weekly review.
  4. We introduced a rhythm: on Fridays, a 20-minute "review" directly in the tool.

Result after 4 weeks:

  • less “where is that?” message
  • clearer task owners
  • fewer status meetings
  • the team began to perceive the tool as support, not as an additional burden

Related blogs

Frequently Asked Questions about Team Deployment (FAQ)

Why is the team ignoring the new tool?

Mostly because there is no clear context, rules and responsibilities. People revert to the familiar when they don't know exactly what is changing.

Is the problem in employee motivation?

Rarely. More often, the problem is in the system: there is no "one source of truth", no standards and no monitoring rhythm.

How many rules are enough?

5-7 clear rules that everyone understands and that are consistently applied are enough.

How do I prevent everything from going back to email?

By defining that tasks and status are managed in the tool, and email remains a channel. Remove duplication and introduce a rhythm of reviews in the tool.

Should we change the tool if the team is not using it?

Not immediately. First check if there is a system (rules, templates, responsibilities). Only when it exists, it makes sense to evaluate whether the tool is right.

Business consulting - Irena Gigovic
Table of contents
Schedule a consultation