How detailed should i make onboarding workflow diagrams for clients?

[Charles_S]

I’m trying to put together a standard operating procedure for our client onboarding, but I keep getting stuck on how detailed to make the workflow diagrams. If I map out every single approval and data entry step, it feels overwhelming, but skipping the minor checks might cause confusion later. How have others balanced this when documenting their core processes?

[David_J]

Early on I tried mapping every tiny approval and data entry for onboarding, and it felt like chasing ghosts. The diagram got so dense I stopped sharing it. What helped me was separating the map into a few big lanes — inputs, decisions, and handoffs — and labeling which steps are essential vs nice to have. Then I kept the rest of the process in a short narrative or checklist so the chart doesn’t explode.

[NoahNG]

I stopped trying to crowd every micro-step into the diagram and split it into three levels: core steps, decision points, and exceptions. The core map shows what must happen, decisions mark where a human or system checks, and exceptions cover what you do if something goes off rails. It feels light but still gives a reference when someone asks why something happened.

[NicholasL]

I wonder if the real problem isn’t the diagram but data readiness or the client’s expectations. We pilot with two accounts, see where steps stall, and ask what outcomes matter most to the client. If the pilot reveals the bottleneck is a single data field, we fix that instead of widening the diagram.

[EvelynVH]

Quick note from last week: I drew a one-page flow with five blocks and a couple of lanes, then handed it to two teammates for quick sanity checks. It was rough, but the feedback was that the chart looked credible and we saved weeks. Then I stopped there because it felt like enough to start conversations rather than lock us into a process we’d have to maintain forever.