---
id: KB-PS-005
url: https://app.codecontract.io/help/getting-started/getting-your-team-to-actually-use-it
idioma: en
categoria: primeros-pasos
subcategoria: recursos
audiencia: usuario
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-PS-003, KB-ET-005]
citadoPor: [KB-PS-013, KB-CR-015, KB-PS-015, KB-PS-017]
---

# Getting your team to actually use it

_The part that is not technical and decides whether any of this works._

**Responde a:** the team is not using the tool · how to train my team · adoption of a new tool · they still use email for everything

Almost every abandoned tool worked fine. What fails is the moment someone is in a hurry and the fast route is still to send an email. If that route stays open, it gets used.

**En corto**

- Start with one convinced person, not the whole team.
- One complete case teaches more than a training session.
- While email still works for the same thing, email is what people will use.

## What works

1. **One person, one process, two weeks** — Have someone genuinely use it for their own work and have it pay off. That convinces more than any demo.
2. **Let that person tell it** — A colleague explaining how they saved three days beats a training session.
3. **Close the old route for that process** — "Supplier onboarding goes through here" has to be a decision, not a suggestion.
4. **Add the next process** — Once the first is habit, not before.

## What does not work

- Training everyone on the same day about something nobody has used.
- Building twelve processes before one is in use.
- Letting each person decide: you end up with two systems and neither complete.

> [!WARNING]
> If someone goes back to email, ask why before repeating yourself. There is almost always a concrete reason — a missing permission, a process that did not cover their case — and fixing it convinces better than restating the rule.

> [!NOTE]
> The sign it has taken hold is not that everyone signs in: it is someone saying "we set this up in there, right?" without being prompted.

**How long until it sticks?**

One process, a few weeks. A whole department, a few months.

**Is formal training needed?**

Rarely. A real case, accompanied, teaches more.

**What about someone who refuses entirely?**

Usually it is whoever moves the most paper. Start by making one concrete thing easier for them.

## Ejemplos

**A company trains twenty people in one session and two months later nobody uses it.**

- Starts again with one person and supplier onboarding
- Three weeks later she explains it at the team meeting
- Onboarding is decided to go through there

→ Three months on, twelve people use it, with no training session at all.

**The tool is announced at an all-hands and nothing happens afterwards.**

- Picks one specific process and one person responsible
- Makes the announcement once it already works

→ A real change is communicated rather than an intention.

**Everyone keeps requesting documents by email because it feels faster.**

- Makes the new way the most convenient for whoever requests
- Stops accepting the old channel once the new one works

→ The change holds without weekly nagging.

**Whoever drives it goes on holiday and usage fades.**

- Shares the process between two people from the start

→ Usage does not depend on one person being around that month.

**The team sees it as one more tool to learn.**

- Starts with what removes work, not with what adds control

→ The first experience is a saving rather than an obligation.

**Nobody knows whether it is being used.**

- Looks at which processes get launched and which stall

→ The adoption conversation happens with data.