---
id: KB-PS-013
url: https://app.codecontract.io/help/getting-started/the-first-thirty-days
idioma: en
categoria: primeros-pasos
subcategoria: configuracion-inicial
audiencia: usuario
nivel: basico
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-PS-003, KB-PS-005]
citadoPor: [KB-PS-016, KB-PS-017, KB-PS-019, KB-PS-020]
---

# The first thirty days

_What to expect each week, and which week the doubt usually appears._

**Responde a:** first month using the platform · simple rollout plan · what to do in the first weeks · how long before it shows

A month is enough to know whether this helps you, provided it is done in a specific order. This is the one that works, with a warning about where the dip is.

## Week by week

| Week | What to do | What you notice |
| --- | --- | --- |
| 1 | One real case end to end, just you | Whether the system fits your case |
| 2 | A full process with real third parties | The first reply from someone outside |
| 3 | Bring the team into that same process | Where people get stuck, which is never where you expected |
| 4 | Automate chasing and review | The first real time saving |

> [!IMPORTANT]
> Week 3 is the dip. It is when the team asks why something that "already worked" is changing, when the exceptions nobody mentioned appear, and when it is decided whether this stays or is abandoned. It is not a sign of failure: it is the week everyone has.

## How to get through week 3

1. **Listen to the specific complaint, not the general one** — "It's slower" almost always means "I can't find X" or "I don't know what's mine".
2. **Fix whatever you can the same day** — Two quick fixes beat a meeting explaining the benefits.
3. **And add nothing new that week** — That is the temptation: adding another process to prove the point. It makes everything worse.

> [!WARNING]
> The commonest first-month mistake is starting by importing the historical archive. It eats week 1, teaches nothing about whether the system suits you, and fills everything before you know where things go.

## What to look at on day thirty

**En corto**

- How often someone had to ask where something stood.
- How long the first full process took versus how you did it before.
- And whether anyone on the team uses it without being reminded.

The third predicts the rest. If at thirty days at least one person logs in of their own accord because it is easier than the old way, the change already stands without you.

> [!NOTE]
> All of this consumes: every upload, send and read counts in the trial month too. It is little, but worth knowing before repeating the same case twenty times to demo it to people.

**What if nobody outside replies in week 2?**

Check the send status before concluding anything: it is usually the recipient, not the system.

**How many people should join in month one?**

Those touching that process. Bringing in the whole company in month one is the fastest way to fail.

**When do we import the old material?**

From month two, and only what gets consulted or expires.

## Ejemplos

**A company starts by importing five years of archive and by week 3 the team is complaining.**

- Stops importing and fixes the two specific complaints
- Returns to the single process until day thirty

→ By month end two people use it unprompted and the archive is brought in later, and only partly.

**The first week goes on configuring and nothing is requested.**

- Launches a real request on day one

→ Week one ends with a reply from outside rather than a screen set up.

**In week two a case appears the process did not contemplate.**

- Adjusts the process for that case and saves it again

→ The template improves through reality rather than being born perfect.

**In week three somebody says email used to be faster.**

- Listens to the specific complaint and fixes that step

→ The objection becomes a change rather than an argument.

**At month end nobody knows whether it helped.**

- Compares how long closing a file used to take

→ The decision to continue is taken with a figure.

**There is a wish to extend to another process before finishing the first.**

- Finishes the first one all the way to closing

→ The second starts on something proven rather than a hunch.