Getting started
The first thirty days
What to expect each week, and which week the doubt usually appears.
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.
Watch out
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
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.
Worth knowing
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.
A real case
The situation
A company starts by importing five years of archive and by week 3 the team is complaining.
What you do
- Stops importing and fixes the two specific complaints
- Returns to the single process until day thirty
What you get
By month end two people use it unprompted and the archive is brought in later, and only partly.
The situation
The first week goes on configuring and nothing is requested.
What you do
- Launches a real request on day one
What you get
Week one ends with a reply from outside rather than a screen set up.
The situation
In week two a case appears the process did not contemplate.
What you do
- Adjusts the process for that case and saves it again
What you get
The template improves through reality rather than being born perfect.
The situation
In week three somebody says email used to be faster.
What you do
- Listens to the specific complaint and fixes that step
What you get
The objection becomes a change rather than an argument.
The situation
At month end nobody knows whether it helped.
What you do
- Compares how long closing a file used to take
What you get
The decision to continue is taken with a figure.
The situation
There is a wish to extend to another process before finishing the first.
What you do
- Finishes the first one all the way to closing
What you get
The second starts on something proven rather than a hunch.
This article answers
- first month using the platform
- simple rollout plan
- what to do in the first weeks
- how long before it shows