Trackline
Changing the contact mid-file
Your contact leaves, changes role or goes off sick, and the file carries on with half of it delivered.
It happens in any process lasting more than a fortnight: the person supplying the documentation drops off the map. The file does not stop for that — it carries on with what they already delivered and what is still missing, which now falls to someone else.
What stays and what changes
| Element | What happens when the person changes |
|---|---|
| What was already delivered | It stays, under the name of whoever delivered it |
| What is missing | Passes to the new person |
| The history of the exchange | Kept: it is what explains where you had got to |
| Links sent to the previous person | They remain live until withdrawn |
Important
The fourth row is overlooked and has real consequences: **sending the link to the new person does not disable the old one's**. Those are two live ways into the same file, and the departed one sits in a mailbox someone else may inherit, or that they keep if the address was personal. Changing participant is not «emailing the link to the new one»: it is granting access to one and withdrawing it from the other, two separate acts that are nearly always half done.
The handover, in order
- 1
Confirm with the company who takes over
Do not assume it because someone answered an email.
- 2
Add the new person to the file
With their real address, not the company's generic one.
- 3
Withdraw the previous person's access
The forgotten step, and the only irreversible one if skipped.
- 4
And summarise in two lines where things stand
Delivered, missing and by when: it saves a week.
Watch out
What delays these handovers is not the admin: **it is that the new person does not know what was asked or why**. They inherit a list of documents with no context and start asking things settled a month ago. Two summary lines when granting access are worth more than any later reminder — and if the history lives in the file rather than in the departed person's inbox, those two lines write themselves.
When it is one of your own who changes
Worth knowing
If the change is because someone left the company, check scheduled sends and reminders going out in their name too: those are the ones still arriving weeks later.
›Do we have to re-request what was delivered?
No: it stands, delivered by whoever was entitled at the time.
›What if the previous person comes back?
Grant access again; the history has not moved.
›Can both be active at once?
Yes, during the handover, and it helps: one is withdrawn afterwards.
A real case
The situation
A company emails the link to a supplier's new contact and considers the handover done.
What you do
- Adds the new one, withdraws the previous access and summarises the state in two lines
What you get
The file moves on without rehashing and with no live access in an unmonitored mailbox.
The situation
The contact leaves with the file half done.
What you do
- Changes the contact and resends what is outstanding
What you get
What was delivered is kept and only the gap is requested.
The situation
The new contact does not know what was delivered.
What you do
- Shows them the file's status
What you get
They catch up without phoning their predecessor.
The situation
Reminders keep going to somebody who has left.
What you do
- Updates the recipient in the file
What you get
Notices reach somebody who can act.
The situation
A new file is opened for the new person.
What you do
- Continues the existing one, changing the contact
What you get
No history is lost and nothing is requested twice.
The situation
Nobody knows who the new contact is.
What you do
- Asks the company's contact before chasing
What you get
The request reaches the right person first time.
This article answers
- changing a file's contact mid-way
- the supplier's contact person has left
- forwarding what is left to someone else
- our contact person has gone