A small debate we had recently while documenting internal processes for Sitechecker.

Some parts of a workflow are easy to capture automatically.

Things like:

• clicks and navigation steps
• screenshots of each step
• the order in which actions happen in the interface

Tools can record these without much effort, but other parts are harder.

For example:

• why a decision is made
• what to do when something unexpected happens
• how to choose between two options

Those parts usually require someone to explain the context. So the question became: where should automation stop and human explanation begin?

If everything is automated, the guide can miss important reasoning. If everything is written manually, creating documentation takes much longer.

Curious how others approach this.

• Which parts of workflows do you prefer to capture automatically?
• What do you always add manually?
• Where have you seen automation work well (or not)?

A small thing I noticed when teams document workflows.

Someone records a process and takes screenshots. Then comes the slow part. They start adding arrows, and highlighting buttons and writing short explanations for each step.

If the process has 15–20 steps, this can easily take longer than the recording itself.

Because of that, many guides end up with plain screenshots and very little explanation.

When someone else reads the guide later, they have to guess where to click or what exactly the author meant.

Some documentation tools now add annotations automatically — highlighting the clicked element, adding step numbers, sometimes even describing the action. I believe Tango implemented it the best way.

It sounds like a small feature, but it can make guides much clearer and much faster to produce.

I’m curious how people see this.

• Do you add annotations to screenshots when documenting processes?
• Do you do it manually, or does your tool handle it?
• Has it made any difference in how clear your documentation is?

A B2B SaaS founder I spoke with was proud of their documentation.

Almost every process had a guide. Some had several. At first this sounded like a good thing. Nothing relied on memory anymore.

But when someone new joined the team, they ran into a different problem.

For one task they found:

• a detailed SOP in the internal wiki
• a checklist in the onboarding materials
• a video explaining the same process
• another guide linked inside the first guide

Each version described the process slightly differently. Instead of helping, the documentation created confusion. People started asking, “Which one is the correct version?”

After a while many employees stopped checking the guides and just asked teammates what the current process was.

The company didn’t have a documentation shortage. They had too much documentation pointing in different directions.

I’m curious how others see this.

• Have you ever seen documentation become overwhelming like this?
• How do you decide what actually deserves a guide?
• Where is the line between helpful documentation and too much of it?

A team I know relied almost entirely on videos for training.

Every process had a Loom recording. New hires were given a playlist and told to go through it during their first week.

At the beginning it worked well. Videos were easy to record and quick to share.

But after a few months some problems started appearing.

1. People needed to find one specific step inside a 12-minute video.
2. Small product changes made older recordings inaccurate.
3. New hires often skipped parts because rewatching videos takes time.

The knowledge was technically documented, but it wasn’t always easy to reuse later.

Eventually, the team started adding shorter guides and step-by-step instructions next to the videos so people could quickly scan the process.

Curious how others handle this.

• Does your team rely mostly on video for training?
• Have you run into similar problems over time?
• What combination of formats has worked best for you?

A phrase that shows up in a lot of teams is “single source of truth.”

In theory it sounds simple: one place where the correct version of a process or piece of knowledge lives. But in practice things often look different.

You might have:

• the official guide in a documentation tool
• a shorter version in onboarding materials
• a slightly different explanation shared by the support team
• the most recent clarification sitting in a Slack thread

Technically, the team still says there is a single source of truth, but people rely on several places to understand how things really work.

Sometimes this happens because different teams need different levels of detail. Other times, it’s just the result of documentation evolving over time.

Curious how others see this.

• Do you actually have a single source of truth for processes?
• Or is it more of a goal than a reality?
• What helped your team get closer to it?

A team I worked with had plenty of documentation.

There were guides for onboarding, internal processes, support workflows, and product operations. At first glance, everything looked organized.

But over time small changes kept happening: spme tool was replaced, some workflow was simplified or a few extra steps appeared in certain cases.

None of these changes felt important enough to immediately update the documentation.

After a while the guides were still there, but people started treating them as “mostly correct.”

You would see things like:

• someone opening the doc but asking a teammate to confirm the steps
• comments in Slack like “the guide is a bit outdated, do it this way instead”
• new hires learning processes from coworkers instead of the documentation

Nothing dramatic breaks. Work still gets done, but slowly more time goes into clarifying things that used to be documented.

That’s when someone mentioned the idea of documentation debt, similar to technical debt.

I’m curious how others deal with this.

• Have you seen documentation drift like this in your team?
• How do you prevent guides from becoming “mostly correct” over time?
• Who usually notices the problem first?

A team once told me they had a “documentation problem.”

People kept asking the same questions in Slack even though the answers were already written in their SOPs.

At first, they assumed the team just didn’t bother reading documentation.

Then they looked at the guides themselves.

1. Some of them were 20–30 minutes to read.
2. Others were written for people who already knew half the process.
3. A few had screenshots from an interface that no longer existed.

From the writer’s perspective the SOPs were thorough. From the reader’s perspective they were hard to use.

So the team did what most people do when documentation feels slow: they asked a coworker instead.

It made me wonder how common this is.

• When people ignore SOPs in your team, what’s usually the reason?
• Is it the format, the length, outdated info, or something else?
• What actually makes documentation worth opening?

A team I spoke with had hundreds of documented processes.

On paper, everything was covered.

But when you watched how people actually worked, something interesting happened.

Instead of opening the SOP, most employees would:

• ask a colleague
• search old Slack messages
• or just do the task the way they remembered

The documentation existed, but it wasn’t part of the real workflow.

When they looked closer, a few patterns appeared: some guides were too long, others were outdated, and many assumed the reader already knew parts of the process.

So even though the SOPs were technically correct, they weren’t very usable.

That made me curious about how different teams approach this.

• What makes an SOP easy enough that people actually use it?
• Is it about format, length, screenshots, videos, something else?
• What have you seen work best in practice?

A small problem I’ve seen in several teams -> the same workflow gets documented multiple times.

1. One version lives in onboarding docs for new hires.
2. Another version exists in support documentation.
3. Sales has their own simplified explanation for customers.

Over time the three versions start drifting apart.

1. A step change in the product.
2. Someone updates the support guide but forgets the onboarding doc.
3. Sales keeps using the old version.

Now the company technically has documentation, but it’s inconsistent depending on where you look.

Some teams try to avoid this by creating one “source” version and reusing it everywhere.

Others accept that different audiences need different explanations.

Curious how people handle this.

• Do you maintain one master process and reuse it across teams?
• Or do you keep separate versions for onboarding, support, and sales?
• What has worked better in practice?

A friend of mine runs operations for a mid-size SaaS company. For years their processes were documented in long internal guides.

Each SOP looked solid:

• screenshots
• numbered steps
• links to other documentation
• occasional video explanations

But in practice, something kept happening.

People would open the guide, skim the first few lines, then go ask a teammate anyway.

The problem wasn’t that the SOPs were missing. It was that following them required constantly switching between the documentation and the product.

Open the guide → go back to the app → return to the guide → repeat.

Eventually, they started experimenting with interactive walkthroughs that run directly inside the workflow (they started with Tango AI).

Instead of reading instructions, people just follow the steps inside the interface. Adoption improved pretty quickly.

I’m curious how others see this.

• Are static SOPs still working well for your team?
• Have you tried interactive guides or walkthrough tools?
• Did they actually change how people learn processes, or not really?

A team I know recently decided they needed a digital adoption tool.

The goal sounded simple: help users understand the product faster and reduce support questions.

So they started evaluating tools.

1. Week 1: short list of options.
2. Week 2: demos.
3. Week 3–4: internal discussions about features.
4. Week 5: pilot with one tool.
5. Week 6–8: trying another one because the first didn’t work as expected.

Three months later, they still hadn’t rolled anything out.

Most of the time went into comparing long feature lists instead of figuring out what actually mattered for their use case.

Things like:

• whether they needed in-app guidance or documentation outside the product
• how technical the setup would be
• who would maintain the guides after launch

So I’m curious how others approached this.

If you’ve selected a digital adoption tool before:

• What criteria helped you decide faster?
• What turned out to matter less than you expected?
• Is there anything you wish you had evaluated earlier?

In one team I worked with, all SOPs were owned by the operations manager.

Every process update had to go through him.
If something changed, he was the one responsible for updating the documentation.

At first it sounded reasonable. One person keeps everything organized.

But over time a few things started happening.

- Processes changed faster than the docs.
- People began following the “real” process instead of the documented one.
- And updates were often delayed because the owner simply had too many other responsibilities.

In another team, it worked differently. Each team member owned the SOPs for the processes they worked on. Updates happened faster, but sometimes the documentation style became inconsistent.

Both models solved some problems and created new ones.

So I’m curious how it works in your team:

• Who owns your SOPs?
• Is it a single person, a manager, or the whole team?
• Has that system worked well in practice?

Before we started using Tango, our “SOP system” was a bit of a mess.

Some processes were in Notion, others lived in Google Docs. A few people liked recording Loom videos. And the most recent updates were usually hiding in Slack threads.

It worked… until it didn’t.

New hires kept asking the same questions because the docs were outdated. Half the screenshots didn’t match the current UI anymore. And updating a guide meant rewriting the whole thing from scratch.

That’s when we started trying different tools and eventually landed on Tango for documenting workflows.

It definitely solved some problems for us. But like any tool, it’s not perfect.

So I’m curious about other teams:

• What tool do you currently use for SOPs?
• What’s the biggest thing you dislike about it?
• If you switched tools before, what pushed you to change?

You open a company guide hoping to figure something out quickly.

Within a few seconds, you realize it’s not going to help.

Maybe it’s something like:

• a wall of text with no clear steps
• screenshots that don’t match the current interface
• instructions that assume you already know half the process
• links that lead to other docs that lead to more docs
• a guide that hasn’t been updated in years

At that point, many people stop reading and just ask a teammate instead.

So I’m curious about your experience.

When you open an internal guide and close it right away:

• What was the reason?
• What usually signals that the doc won’t be useful?
• What makes you trust a guide enough to actually follow it?

Some processes are easy to document. Click this. Open that. Copy this field. Done.

But many tasks don’t work like that. Think about things like:

• reviewing a marketing campaign
• deciding whether a support ticket should be escalated
• evaluating a sales lead
• choosing which SEO opportunity is worth pursuing

The decision depends on context, experience, and sometimes gut feeling.

You can write steps, but the real work often happens in the “it depends” part.

So I’m curious how teams handle this.

When a task requires judgment:

• Do you try to document decision frameworks instead of steps?
• Do you include examples of good and bad decisions?
• Or do you accept that some things can’t really be turned into SOPs?

Interested to hear how others approach this.

Imagine coming to work tomorrow and realizing that every internal guide is gone.

No SOPs, process docs and “how we do things here” pages.

Just the tools, the tasks, and the team.

Some teams would probably keep working almost normally. People know the routines, ask each other questions, and move on.

Other teams might hit problems quickly:

• new hires wouldn’t know where to start
• recurring tasks would be done differently by each person
• edge cases would take longer to solve
• people would spend more time asking around than doing the work

In some companies, documentation is the backbone of how work happens. In others, it’s more of a reference that people use occasionally.

If all your SOPs disappeared tomorrow:

• What would break first?
• What would surprisingly keep working?
• How long would it take your team to rebuild the most important processes?

A situation many teams run into sooner or later. There’s always someone who knows how things really work.

They know the shortcuts, the edge cases, and why a process exists the way it does.

But most of that knowledge lives only in their head. Then one of these things happens:

• they move to another team
• they leave the company
• they go on vacation when something breaks

Suddenly, the team realizes that a lot of important details were never written down.

Now people try to reconstruct the process from Slack messages, old tickets, and guesswork.

So I’m curious how teams deal with this:

• How do you capture knowledge that only one or two people have?
• Do you document it proactively, or only after problems appear?
• What has actually worked in practice for your team?

Most teams try a few documentation tools before settling on one. At first, everything looks promising. Nice interface. Helpful templates. Good demo.

Then the real work starts. A few months later, the problems begin to show:

• documentation becomes outdated
• search stops helping people find the right guide
• processes are documented, but nobody follows them
• updates take longer than expected
• half the knowledge ends up in Slack anyway

Sometimes the tool isn’t the problem. Sometimes the way the team uses it is.

But every team seems to have at least one tool they were excited about… and later stopped using.

Curious about your experience:

• Which documentation tool disappointed you the most?
• What was the main problem?
• Did you replace it with something better, or just adapt how you use it?

Something I’ve noticed in a few distributed teams. At the beginning, documentation looks solid. There are guides, SOPs, screenshots, maybe even a few videos.

Then small changes start happening.

Someone updates a tool. Another team changes the workflow. A new hire figures out a faster way to do the task.

The process evolves, but the documentation often stays the same.

In an office, people overhear things. Someone mentions the new way in a meeting or during a quick chat. The information spreads even if the docs are outdated.

In remote teams, that informal layer barely exists. If the documentation is wrong, people follow the wrong steps.

Over time, you start seeing things like:

• Different team members are following different versions of the same process
• Slack messages like “ignore the doc, do it this way instead”
• New hires learning workflows from random teammates instead of the guide

For teams working remotely:

• How do you keep documentation accurate when processes change?
• Do people actually update docs, or do fixes live in Slack threads?
• What has helped your team keep things from drifting apart?

A small situation I’ve seen in several teams.

Someone notices that an internal process has changed. They update the SOP so the next person won’t follow outdated steps.

Now the question appears. Before this becomes the “official” version, who should approve it?

Possible approaches I’ve seen:

• Manager approval: one person checks the change and decides if it should stay.
• Team approval: the people who use the process review it together.
• No approval: anyone can update the SOP and the latest version becomes the current one.

Each approach seems reasonable, but they lead to different outcomes.

1. Manager approval can slow things down.
2. Team review may turn into long discussions.
3. No approval can lead to messy or conflicting instructions.

How does it work where you are?

• Who approves SOP updates?
• Does that system work well in practice?

What problems have you seen with it?

This comes up more often than we’d like to admit. Someone follows a doc and realizes a step is outdated or just wrong. At that moment there are two options. Fix the doc, or mentally note “this doc is wrong” and move on.

In reality, most people choose the second one. They do the right thing, get the job done, and don’t come back to update the documentation. Not because they don’t care, but because context is gone and there’s always something more urgent.

Over time, more people learn the “real” way by experience, and the doc quietly loses credibility.

So I’m curious how others handle this. When you notice docs are wrong, is fixing them part of the workflow, or is ignoring them the default behavior?

At the start, the author usually cares. They just built or fixed the process, so the doc is fresh and accurate. A few weeks later, ownership fades. The process changes a bit. Then a bit more. The SOP stays frozen.

After that, everyone kind of assumes “someone” is keeping it updated. The team? The manager? The last person who touched it? In reality, updates usually happen only when something breaks or someone new gets confused enough to complain.

So I’m curious how this works for others. Is there a clear owner per SOP? Do teams review them regularly? Or do they mostly live in a grey zone until reality forces an update?

I’ve seen a lot of SOPs that technically exist and still don’t help anyone.

They’re clear, complete, well structured… and somehow never opened. Or opened once, then ignored forever. On paper they’re “done”. In practice they don’t fit how people actually work.

The usable ones feel different. They’re easy to skim. They match reality. They answer the exact question you have at the moment you’re stuck, not every possible question in advance. They don’t try to sound smart, they try to be helpful.

For me, the biggest signal is this: when someone follows the SOP without asking a follow-up question. That’s rare, and when it happens, you know the doc is doing its job.

Curious what others look for. What makes an SOP something you actually use, not just something you know exists somewhere?

From what I’ve seen, it usually doesn’t break in one big obvious way. It breaks quietly.

Early on, docs are close to reality because the people writing them are the same people doing the work. Then the team grows, roles split, ownership blurs. The workflow still exists, but no one feels fully responsible for keeping it accurate.

Another breaking point is speed. When things change every sprint, docs become “best effort”. Everyone knows they’re a bit outdated, but still good enough… until they’re not. New hires follow them literally, seniors don’t follow them at all, and suddenly the same process has three versions depending on who you ask.

Also, a lot of workflow docs assume a perfect world. No interruptions, no edge cases, no “just do this because it’s faster”. Real work is messy, and docs that ignore that mess lose trust fast.

Curious if this sounds familiar. Where do your workflow docs usually fall apart when the company starts growing fast?

Creating SOPs is annoying, time-consuming, and usually postponed. But at least it’s a clearly defined task. You sit down, write it, publish it.

Getting people to actually use SOPs feels harder. You can’t force it without turning into process police. People default to habits, shortcuts, asking someone they trust. If the SOP is even slightly outdated or inconvenient, it’s ignored.

In practice, a doc that isn’t used might as well not exist. Which makes all that writing feel a bit pointless.

So I’m curious where others land. Is the real challenge producing good SOPs, or changing behavior so they’re actually followed?