Onboarding a client into a shared workspace

Set it up before the kick-off, not during

A client's first view of the workspace should show their project, already structured, with real milestones and real dates. An empty workspace at a kick-off call communicates that this is a tool you are asking them to help you populate, which is not a favour anyone grants enthusiastically.

Before the call, translate the statement of work into milestones with dates, owners and acceptance criteria. Add the tasks for the first milestone only — enough to look substantive, not so much that the plan looks fixed for six months. Attach the signed scope so the source document is one click away.

The message you want the client to receive in the first ten seconds is that the project is already organised and this is where they will see it, not that they have been assigned homework.

Spend ten minutes of the kick-off on the workspace

Not thirty, and not a training session. Ten minutes, covering three things: where to see current status, where the things waiting on them appear, and how approval works.

That third item deserves the most attention, because it is where money and time are decided. Show an approval request, show the acceptance criteria attached to it, and be explicit that approving is a recorded decision. Say plainly that this protects both sides, which is true and lands better than leaving it implied.

Then stop. Anything beyond those three things is detail they will not retain and do not need. The workspace has to be legible without training or it will not survive the month.

• Where status lives, and that it is current rather than a weekly snapshot.
• Where their open items appear, so being the bottleneck is visible to them.
• How approval works, what the criteria mean, and that the decision is recorded.

Decide who the approver is, in the room

The kick-off is the last comfortable opportunity to establish who signs off. Later it becomes a delicate question, because by then it usually means telling someone their opinion is not decisive.

Ask directly: who approves a milestone as complete. Then record the answer in the workspace so it is documented rather than remembered. Other stakeholders can be added as reviewers who comment without approving, which gives them a legitimate role and keeps the decision with one person.

If the honest answer is a committee, accept it and adjust the plan rather than pretending otherwise. Committee review takes longer and produces contradictory feedback, and building that into the schedule at kick-off is far easier than explaining a slipped date later.

Be deliberate about what you share

Over-sharing is as damaging as under-sharing. A client who sees every internal task, draft and half-finished exploration will form opinions about work you were not ready to show and ask questions that consume delivery time.

Share milestones and their status, deliverables ready for review, decisions and open questions, and dates. Keep internal task breakdowns, resourcing, budget position, margin and drafts on your side of the line until they are ready.

The right mental model for the shared view is a well-run project dashboard, not a window into your workshop. Clients want to know where things stand and what needs them. Almost none of them want your task list.

Redirect the first few email threads, gently

In week one your client will email you something that belongs in the workspace — feedback on a deliverable, a question about a date, an approval. How you handle those first three messages determines the next six months.

Answer the question, because being unhelpful to make a process point is a bad trade. Then add the substance to the workspace and reply with a link: I have put this against the milestone so it stays with the deliverable, here it is. You have answered them and you have moved the record without asking them to do anything.

Do that consistently for two weeks and most clients migrate on their own, because they notice the link is where the context is. Do it inconsistently and email wins, because email always wins by default.

Handle the stakeholder who will never adopt it

Sometimes there is a senior stakeholder who is simply not going to open a workspace. It is not obstruction; their working life is an inbox and a calendar and that is not going to change for your project.

Do not fight it. Configure email notifications so approval requests and status summaries reach them where they are, with the approve action in the message. The record still lands in the workspace, and the plan stays current. You wanted the record, not their behaviour change.

This is worth designing for rather than treating as a failure. A workspace that only works when every stakeholder cooperates is a workspace that will not work.

Check adoption at two weeks and adjust

Two weeks in, look at whether the client has opened the workspace, whether approvals happened there or in email, and whether your team is maintaining it or quietly running a second plan elsewhere.

If the client is not engaging, the usual causes are that the shared view carries too much detail to scan quickly, or that email remained the faster path for something they need often. Both are fixable in an afternoon: reduce what is shared, and make sure the thing they need most is the first thing they see.

If your own team is running a shadow plan, that is the more urgent signal, and it usually means visibility controls are not granular enough to let one plan serve both audiences. Fix that before the shadow plan becomes the real one.