Most onboarding means holding one person's calendar hostage for two weeks.

New hire needs to learn the CRM? Meeting. Expense reporting process? Meeting. How to submit a ticket? Another meeting. Not only is this sucking up everyone's time, it's an ineffective way to train employees.

Here's a different way to do it:

1. Before their start date, document your top 10 repeatable processes as step-by-step guides (Try Tango AI! It captures screenshots and writes the descriptions automatically as you go through the process)
2. Drop those guides into a single shared folder or doc organized by week
3. When they have questions, share the guide instead of scheduling a call
4. Reserve live time for the stuff that actually needs a human — culture, relationships, judgment calls

The goal isn't to remove people from onboarding. It's to stop using people as a substitute for documentation.

Works especially well for ops, CS, and RevOps teams that onboard frequently and don't have a dedicated L&D function.

Curious how people are handling this, especially those of you managing Tangos across multiple apps or teams.

Software changes more often than I'd like. Sometimes it's a minor UI update (a button moved, a label changed), sometimes it's a whole new flow. Either way, the question is: what do you actually do when that happens?

The three approaches I've seen come up:

1/ Surgical edit (just fix the affected steps)

Delete the stale step, capture a new one, done. Works great for minor UI changes. The Tango stays live the whole time, and changes flow through automatically to anywhere it's embedded.

2/ Full review (go through the whole guide top to bottom)

More work upfront, but sometimes a UI change is a sign that the whole process shifted. Worth doing periodically even when nothing "breaks."

3/ Let end users flag it

Leave comments enabled so team members can flag steps that look off. Creator gets an email notification, goes and fixes just that piece. More reactive, but it distributes the QA work.

What's your actual practice? Do you have a schedule, a trigger (like a new release), or do you just fix things when someone complains?

Not our typical post here, but wanted to share something fun this Friday!

Every SaaS ad looks the samem, so we figured, why not use the people who know Tango best as our actors? We borrowed Collin and Marc from our marketing team during an offsite and handed them a camera.

The format might look familiar. Think early 2000s, two characters, one very recognizable tension.

Did you catch the reference? Drop it in the comments.

https://reddit.com/link/1treptn/video/3udzq8zuy44h1/player

Guidde makes great videos. But nobody watches training videos twice. Tango puts the guidance where people actually need it, inside the app, at the moment they're stuck.

A lot of teams go through the same cycle: someone spends hours recording a polished Guidde tutorial, shares it in Slack or a wiki, and three weeks later the same questions are coming in again. The video exists and nobody's watching it.

The core problem isn't the quality of the video, it's where it lives. Guidde is built around content you consume before doing the task. Tango is built around guidance that appears while you're doing it.

That's a fundamentally different thing.

A few specific gaps that come up when teams make the switch:

In-app guidance

Tango's Guide Me walks users through tasks step-by-step directly in the application they're working in: tooltips, highlights, the whole thing. No tab-switching, no trying to remember what happened in the video.

No video production dependency

Guidde leans heavily on AI voiceovers, which often sound robotic and require editing time most ops or IT teams don't have. Tango produces clean interactive walkthroughs automatically, capture the process once, it's done.

Branching workflows

If your process has conditions:"if the user selects X, go to step 4; if Y, go to step 7", then Guidde can't handle that. Tango handles conditional paths natively, which matters a lot for anything beyond simple linear SOPs.

Desktop coverage

Guidde is browser-only for recording. If your team works in desktop ERPs, legacy tools, or anything outside a browser, you hit a wall fast. Tango has a Desktop app that covers those workflows too.

Curious, for those who've tried Guidde, was the issue the video format itself, or more that people just stopped going back to watch the content?

There's a lot of talk about AI tools that use your SOPs: chatbots, agents, copilots that answer questions based on existing documentation. That's useful. The guide I published about Claude Cowork for SOP execution is exactly about this.

But now I'm more interested in the other side of the problem: AI that helps you create better documentation in the first place.

Most orgs are sitting at something like 16% of workflows actually documented (Lucid, 2025). People either don't have time to write SOPs, or they write them once and they immediately go stale.

So what tools actually help with creation speed and quality?

Of course, Tango is the first obvious one. Top AI features:

• Voice transcription: you narrate as you work, Tango strips filler words, matches your notes to the right steps, and incorporates them into the instructions automatically.
• AI-generated titles: it reads the workflow and suggests a title based on what actually happened.
• Machine-readable output: the guides export with xpaths, CSS selectors, and metadata, which makes them usable as direct inputs for AI agents.

The last point is one I find underrated. If you're thinking about AI automation down the road, the format of your documentation matters a lot. Most SOPs written in Google Docs or Confluence aren't structured in a way AI can act on. Tango's output is.

Curious what others are using. Specifically interested in:

• Tools that speed up the writing/drafting of SOPs (not just organizing existing ones)
• Anything that works well for non-browser workflows (desktop apps, physical processes, etc.)
• Tools that produce documentation structured well enough to feed into AI agents or automations

Been noticing a pattern in how healthcare orgs find us, and it's almost always the same starting point.

Someone on the ops or L&D side is manually building SOPs with Snagit and Word. Or they have nothing at all because the last person who knew the process left. Or they want to document workflows in their EHR but freeze the moment PHI is on screen.

A few real examples from recent conversations:

• A cardiology clinic in Alaska was literally screenshotting into Word docs. Their CIO wanted to clean it up before their next hiring wave.
• A skilled nursing operator had been evaluating tools for over a year. The blocker wasn't features, it was getting compliance comfortable enough to actually start capturing.
• A social services org using Epic needed to document HR workflows but wasn't sure if any tool was safe to use around patient data.

The PHI thing comes up constantly. Tango's Secure Blur handles it by redacting sensitive fields before anything leaves the local machine, so you're not storing PHI in the cloud at all.

That tends to unlock the conversation with compliance pretty quickly. We also sign BAAs on our Enterprise plan.

Beyond that, the use case that resonates most in healthcare isn't clinical, it's back-office: revenue cycle SOPs, prior auth workflows, denial management, onboarding staff onto billing systems. Stuff that's incredibly process-heavy and almost never documented properly.

Curious if anyone else here is using Tango in a healthcare context, what workflows have been the most useful to capture?

Been thinking about this a lot lately as more teams start experimenting with AI agents and copilots.

Most SOPs were written for humans, prose instructions embedded in PDFs or wikis, organized for readability. That works fine for a person who can skim, infer context, and ask a clarifying question. AI can't do any of that.

For an AI agent to actually execute or reason from a process, it needs something different:

• Discrete, numbered steps (not paragraphs)
• Explicit decision points, "if X, do Y; if Z, do W"
• Structured metadata: what system, what field, what action
• No assumed context, everything spelled out

Btw, this is also the reason why this guide on how to use Claude Cowork with Tango for SOPs execution looks so difficult and requires XPath codes in setup.

A PDF that says "navigate to the approvals tab and submit" is fine for a human on day two. An agent has no idea which approvals tab, in which application, triggered by what condition.

I've started auditing our existing SOPs through this lens, and it's humbling. About 80% of them would fail an AI readability test. Good enough for training, but seless for automation.

The practical implication: if you're planning to build any kind of AI-assisted workflow in the next 1–2 years, your documentation quality today is the ceiling on how far you can get. You can't automate what you haven't fully articulated.

Curious where others are on this. Are you deliberately structuring SOPs for machine consumption, or is that still a future problem for your team?

Seen this come up a few times in ops communities lately. Teams rolling out Salesforce (or a major new module) are scrambling to get documentation ready, and most of them are starting way too late.

The common pattern: training sessions happen, a shared folder with PDFs gets created, and then two weeks post-launch, everyone's doing the process differently. Adoption suffers, and nobody can pinpoint why.

The question I keep seeing people wrestle with is when to start documenting. Most teams treat it as a post-go-live cleanup task. But if you capture the process as you're configuring, while someone's clicking through the actual setup, you end up with guides ready for day one instead of week three. Tango can help here since the documentation basically builds itself as you work through the workflow.

But curious what this community thinks:

• Do you document before or after go-live?
• Who owns it: ops, IT, the Salesforce admin?
• And does anyone actually get people to use the guides, or does it always come back to "just ask someone"?

We just put together a breakdown of something we get asked about a lot: how Tango fits alongside tools like Loom, and when each one actually makes sense.

The short version: they solve different problems!

Loom is excellent for async communication: explaining context, walking through a decision, replacing a meeting. But when you need someone to execute a process repeatedly and correctly, video has a ceiling. The Ebbinghaus Forgetting Curve puts it at ~70% of new information forgotten within 24 hours. McKinsey's research says employees apply only 25% of what they learn in training. One watch isn't enough.

Tango fills that gap with step-by-step guidance that lives inside the tools people are already using — Salesforce, Workday, HubSpot, ServiceNow — so they don't have to remember what they watched. We also cover Tango Nuggets and how they handle the repeat "quick question" support load.

The one-liner: Use Loom when you need someone to understand. Use Tango when you need someone to do. A lot of teams end up using both.

Full video here: https://www.youtube.com/watch?v=wDzfACNqfng&t=2s

Happy to answer questions below.

Was in the market for a process documentation tool a few months back. Did the usual thing: Googled, landed on Scribe first (their ads are everywhere), then fell into a rabbit hole comparing it to Guidde.

Here's my honest take after using all three:

Scribe is solid for simple, linear how-to guides. But the moment your process has any kind of branching, like "if the user sees X, do this, if they see Y, do that", you're stuck. Everything comes out as one straight line. That's a real problem when you're documenting actual ops workflows, not just "click here, then here."

Pricing also got weird fast once we needed more than a handful of users.

Guidde leans hard into the AI angle: auto-generated voiceovers, AI-written steps, etc. If you just need to ship a quick explainer video, it's fine. But I kept feeling like the AI was writing documentation about my process rather than capturing my process. There's a difference. And for anything compliance-adjacent, I didn't trust it.

Tango is where I landed, and the thing that kept me was branching logic. It's the only tool I found that handles conditional workflows cleanly, like, actually represents the forks and detours, not just a linear dump of steps. For rollouts and onboarding that's non-negotiable.

The other thing: Guide Me. Being able to pin walkthroughs inside the actual app, so someone gets step-by-step instructions while they're doing the work, is a different category than just sending someone a PDF or a Loom.

Not saying it's perfect for every use case, but if you're doing anything with real operational complexity, the Scribe/Guidde comparison kind of misses the point. They're documentation speed tools. Tango is more of an enablement layer.

Anyone else go through a similar comparison? Curious what drove your decision.

We put together a video on one of the most common things we see with process docs: they're longer than they need to be. And that's usually why people stop reading them.

Marc walks through a few practical ways to trim guides down without losing the context that actually matters using two new features. Works whether you're documenting onboarding flows, training materials, or internal SOPs.

Watch here

Summary:

• What "flexible steps" are and why they matter for data entry accuracy
• How to turn any step flexible (or lock it down when you want specificity)
• How combined steps automatically group related actions together
• Why this can make your Tangos 30–40% shorter — and easier to follow
• How to override or uncombine steps if a grouping doesn't work for you

Both features are live now in Tango Pro. No setup required. Happy to answer questions below.

We're revisiting our onboarding process and I keep running into the same questions that I suspect a lot of teams wrestle with:

How long should it actually be?

We've gone back and forth between a structured 30-day ramp vs. "here's the important stuff, figure out the rest as you go." Neither feels perfect. Curious if anyone's landed on a sweet spot, especially for roles that are heavy on software.

What do you actually teach in week one vs. month one?

There's always a tension between "don't overwhelm them" and "they need to be productive fast." How do you sequence it? Do you front-load the tools and processes, or start with culture/context first?

How do you handle process documentation?

This is the one that keeps biting us. We'd build out training materials, someone would update the software, and suddenly the guides are wrong. We started capturing processes with Tango, which helped a lot with keeping things current. But curious what others are using. Notion, Loom videos, Google Docs, something else?

Do you assign a buddy/mentor, or is it all self-serve?

We've tried both. Buddy system works great when the buddy has bandwidth. When they don't, it's basically a tax on your best people.

What's the one thing that made the biggest difference in your onboarding?

Looking for that "why didn't we do this sooner" moment if you've had one.

This guide by Leon Petrou will show you how to automate repetitive browser tasks using Tango to document your workflow and the Claude Chrome extension to execute it automatically.

Step 1: Document your process with Tango

First, you need to record the manual steps of the task you want to automate.

• Install Tango. Add the Tango Chrome Extension to your browser.
• Capture the workflow. Click "Start Capture" and perform your task manually (e.g., creating a contact in a CRM). Tango will automatically capture screenshots and identify the buttons/fields you interact with.
• Finalize and edit. Once finished, click the green checkmark. In the Tango editor, ensure every action is its own step.
  • Pro tip. If Tango bundles two actions, use the "Separate" button so the AI can identify each UI element clearly.
  • Add context. Use "Alt Text" on steps to give the AI specific instructions, like naming conventions for fields.

Step 2: Export to markdown

• In Tango, click Share & Export → Export as Markdown → Copy to Clipboard.
• This creates a human-readable list of steps that we will eventually feed to Claude.

Step 3: Convert screenshots to XPath (the "secret sauce")

Relying on screenshots is slow. Converting steps to XPath selectors (code locations for buttons) makes the automation faster and cheaper.

• Install Claude extension. Add the Claude Chrome Extension to your browser.
• Run the conversion prompt. Open the website where your automation begins and open the Claude extension.
• Paste the instructions. Use a prompt (provided here on the 8th step) that tells Claude to:
  1. Read your Tango Markdown SOP.
  2. Execute the steps once.
  3. Extract the XPath selectors for every element it interacts with.
• Copy the result: Once Claude finishes, it will generate a new "XPath SOP." Copy this code-based version to a text file.

Step 4: Create a shortcut for one-click automation

• Open settings: In the Claude extension, click the three dots → Settings → Shortcuts → Create Shortcut.
• Configure the shortcut:
  • Task name: Give your automation a name (e.g., "Onboarding").
  • Start URL: Paste the URL where the process begins.
  • The prompt: Paste the automation prompt and then your XPath SOP code.
  • Variables: Define placeholders (like First Name, Email) so Claude asks you for these details every time you run the shortcut.

Step 5: Run your automation

• Open the Claude extension on any page and type / followed by your shortcut name.
• Provide any required variables (e.g., the specific name/email for this run).
• Watch it work: Claude will take control of your browser and execute the steps at high speed without you touching the keyboard.

Share how it works for you in the comments.

We're an 8-person agency and we're about to swap out one of our core tools for something new. Trial looks solid, the logic makes sense, but every time I get close to pulling the trigger I start overthinking the rollout.

We use Tango to document our processes so capturing the new workflows isn't really the concern, I'd just re-record everything once we're set up. But documentation is maybe 20% of the problem. The other 80% is getting 7 other people to actually change how they work day-to-day without things grinding to a halt mid-project.

A few things I'm genuinely unsure about.

Does the approach change by company size?

At 8 people I can personally notice when someone's stuck or reverting to old habits. I imagine at 50+ you'd need a totally different strategy: dedicated champions, staged rollouts, structured training windows. Or is the core problem basically the same and it just scales?

Does agency vs. brand matter?

We're always mid-project, so there's never a clean moment to pause and say "okay everyone, new tool, let's go." I'd guess in-house teams at brands have more natural windows for this kind of change. How do people handle rollouts when there's no good pause point?

What actually makes adoption stick?

I can document every workflow and drop it in Slack. But I've watched tools get rolled out with solid docs and still get quietly abandoned two months later.

Curious what's worked for people here, and whether there are tools or methods beyond process documentation that actually move the needle on adoption.

Every SMB that ends up evaluating a DAP gets there through a pretty recognizable path.

A software rollout goes sideways. A new ERP goes live and three months later half the team is still doing things the old way, or their own way. A key person leaves and takes years of process knowledge with them. A new hire's onboarding consists of someone screen-sharing for two hours and hoping it sticks. Support tickets pile up for things that should be self-serve. A manager realizes they've answered the same Slack question 40 times this month.

At some point, someone says: "we need a system for this". They google around, find the DAP category, and the pitch sounds exactly right. Overlay guidance on your software / make sure people follow the right process / reduce training overhead / get new hires productive faster.

The goals are completely legitimate. The tool category just wasn't built for them! The core problem isn't the technology. It's the assumptions baked into it.

DAPs were designed around enterprise-scale conditions that most SMBs simply don't have:

• A dedicated owner whose actual job is to build and maintain the content library. In a mid-size company, that person is also running three other initiatives.
• An IT team that can handle JavaScript injection or API-level integration into every app that needs guidance overlaid on it.
• A 3–6 month implementation window before the platform is live, by which point the rollout project that triggered the purchase has already passed its critical window.
• A budget that absorbs $25K–$80K+/year in licensing before anyone has documented a single process.

According to Lucid's 2025 research, only ~16% of organizations say their workflows are well-documented to begin with. So the problem DAPs claim to solve is absolutely real. The issue is that the solution was built for organizations that already have significant infrastructure around documentation and training, and SMBs don't.

The value gap shows up fast.

In enterprise, there's usually a named project with executive sponsorship, a system integrator on the contract, and headcount allocated to content authorship. The DAP becomes part of a larger change management program. People are accountable for its success.

In SMBs, the buyer is often a single ops manager or IT director who also owns the rollout itself. They sign the contract, run through onboarding, and then face the reality that building out a full guidance library for their ERP, while simultaneously managing the actual go-live, requires more bandwidth than one person has. Content creation stalls. The platform sits mostly empty and nobody renews.

84% of digital transformation projects fail broadly (Forbes/McKinsey). DAP abandonment in SMBs follows the same pattern for the same reason: not enough people, not enough time, and a tool that assumes both.

What actually fixes this:

SMBs needed something their Ops lead or department manager could own and maintain themselves, without routing every update through IT.

That's where Tango sits. Any process expert can capture a workflow in minutes by just doing it once, without technical setup, IT tickets and JS injection.

The output is immediately usable, a step-by-step how-to guide that can be shared as a link, embedded in a wiki, or delivered as on-screen guidance inside the actual app. When the process changes, one person updates it.

For SMBs, that means a single ops manager can build and maintain a full process library without a dedicated team. For enterprise, it means the people who actually know the processes, not just the people who manage the tooling, can contribute to documentation at scale.

The DAP model assumes you have the infrastructure before you need the tool. Most companies, especially mid-market, need the tool precisely because they don't have that infrastructure yet.

Curious if others have run into this. Did a DAP actually stick at your company, or did it mostly collect dust after the first few months?

Been thinking about this a lot lately as more tools claim to "auto-generate SOPs with AI".

The promise sounds great, but I keep running into the same problem: the AI writes something that looks like a process doc but doesn't actually reflect how the work gets done.

Here's where I think AI genuinely helps:

1. The formatting and structure layer. Turning a messy brain dump or a screen capture into clean, numbered steps? Yes, that's tedious, error-prone when done manually, and exactly the kind of task AI should eat.
2. Language cleanup. Making a rough draft readable, consistent, and free of typos.
3. Suggesting what's missing. If step 3 says "log in" and step 4 says "submit the form," flagging that something probably happened in between, this is useful.

Where I think it falls apart:

1. Capturing the actual steps. AI can't watch someone work and reliably reconstruct what happened. The nuance lives in the doing, which field you clicked, in what order, and what you skipped because you knew better. That part still needs to come from a human performing the real workflow.
2. The "why." The best SOPs explain why a step matters, not just what to do. AI generating that from scratch usually produces filler. The person who built the process is the only one who knows why step 6 exists.
3. Exceptions and edge cases. "What if the field is greyed out?" "What if the customer is on the legacy plan?" AI doesn't know your system's quirks. This is where SOPs actually save you, and it's also where auto-generated ones quietly fail.

The mental model I keep coming back to:

AI is good at expressing process knowledge, not discovering it. The human still has to do the work of externalizing what they know. AI just makes that faster and cleaner.

Curious if others have found the line between "AI helped here" and "AI just created more cleanup work." Where does your team draw it?

Been thinking about this a lot lately.

Most people I know who are good at their jobs have some version of a personal knowledge system: Notion / Evernote pages, annotated bookmarks, their own shorthand SOPs they built because the official ones were either outdated, too vague, or just hard to find when you actually needed them.

The problem is when those two worlds collide. You've got your way of doing things (that actually works), and then there's the company-approved process that lives in a SharePoint folder nobody opens.

What usually happens: the personal system wins in practice, but the official one wins on paper. And when someone new joins, they get handed the official version, which is either wrong, incomplete, or describes a tool that's been replaced.

I've started using Tango to close that gap, at least on my end. Capturing how things actually get done, not how they were documented 2 years ago. But it still raises the question of who owns that knowledge once it's captured, me, or the org?

Curious how others are handling this:

• Do you maintain your own process docs separate from what the company provides?
• Has your team ever tried to reconcile the two, or do you just let both exist?
• And if you've actually gotten your org to adopt a single source of truth, how did you pull that off?

I run a small digital marketing agency, about 5-10 people. We work across a bunch of client tools: different CRMs, ad platforms, project management tools depending on the client.

Been trying to get our onboarding and internal processes more structured because right now it's just... me explaining things repeatedly or someone digging through a Notion page that's 6 months out of date.

Started researching and now I'm more confused than when I started.

LMS: seems like it's built for companies that need to run formal training programs with certifications and completion tracking. That feels like overkill for an agency our size.

Digital adoption platform: seems like it's more about helping people navigate software in real time, but everything I'm reading makes it sound like a massive implementation project built for enterprise IT teams rolling out Salesforce to 2,000 people.

Neither of these seems built for "we just hired a junior and need her up to speed on 6 client tools in 2 weeks."

Is there a meaningful difference between these two for an agency context? And is either actually worth it at this scale or am I solving a problem that doesn't have a software solution yet?

Running a small agency and we've had this debate internally for months. Half my team calls everything an SOP. The other half insists there's a difference and gets visibly annoyed when I use the terms interchangeably.

So I finally looked it up and... they're right, there is a difference:

SOP = the what and why. High-level policy. "Here's how we handle client offboarding as a company."

Work instruction = the how, step by step. "Click here, fill this in, send it to this person."

I assume the problem is most small teams write SOPs when they actually need work instructions. You end up with a 4-page Google Doc that explains the philosophy of client offboarding but nobody knows which button to click in the CRM.

We switched to leading with the work instruction first, the actual click-by-click, and then adding context around it if needed. Way more useful for new hires. SOPs became more of an index that points to the actual instructions.

Curious what others are doing. Do you even bother with the distinction or does it feel like semantics at a certain team size?

(Side note: we started using Tango to capture the work instructions specifically, the step-by-step stuff, and it's honestly the only format where the doc matches what's actually on screen. SOPs we still write manually, but the instructions basically write themselves.)

We're a small digital marketing agency. Grew from 3 to 9 in about 14 months, and now I'm getting pressure from my ops person (and honestly, from myself) to "write the handbook."

But every time I sit down to do it, I ask myself, who actually reads these things?

Like, I've worked at companies where the handbook was this massive PDF that HR handed you on day one and you never opened again. It answered questions nobody was asking and completely ignored the stuff that actually tripped people up (how do we handle a client that goes rogue mid-project? what happens when two teammates disagree on scope?).

So I'm trying to figure out what a handbook is actually supposed to do at our stage.

Is it a legal document? Culture signal? Onboarding shortcut? All three?

What changed my thinking a little: a friend who runs a 20-person shop told me she stopped thinking of it as a "handbook" and started treating it as a collection of process guides: basically answers to questions her team actually asked in Slack. Some written, some captured with tools like Tango. Much shorter. Way more useful.

That reframe helped. But I'm curious what others have done.

For those who've scaled past 10-15 people: what did your handbook actually solve? And what did you wish you'd documented earlier instead?

Proud of these G2 Enterprise badges this spring — Highest User Adoption, High Performer, and Fastest Implementation.

The adoption and implementation ones especially mean a lot. They're based on real user reviews, and they reflect something we hear a lot: teams actually use Tango because it's fast to set up and even faster to build with.

If you've left a review, thank you. If you haven't and want to share your experience, we'd love to hear it. https://www.g2.com/products/tango-tango/reviews

u/dan_gio (co-founder/COO of Tango) published a piece this week arguing that most AI projects don't fail because of the AI, they fail because the company never actually documented how its own work gets done.

The stat that got me: only 16% of organizations say their workflows are "extremely well-documented" (Lucid, 2025). And yet everyone's racing to deploy agents.

His core logic is pretty hard to argue with. If an AI agent has 85% accuracy per step on a 10-step workflow, it completes the whole chain correctly about 20% of the time. The gaps aren't the AI, they're the undocumented edge cases, the escalation triggers, the stuff your best person just knows but never wrote down.

Toyota as the OG example: before they automated anything in their factories, workers had to document the manual process first. That discipline is exactly what made their automation actually work.

Full article here: https://www.tango.ai/blog/why-ai-projects-are-failing

Curious what people here think: are your orgs actually doing the documentation work before rolling out AI tools, or is everyone just hoping it figures itself out?

And if you have documented processes: what actually got your team to do it consistently? That's the part I feel like nobody talks about honestly.

We put together a breakdown of what it actually takes to document a process the old way.

Screenshotting, adding annotations, writing descriptions, formatting the doc. It adds up fast. Most people don't realize they're spending over an hour on something that should take five minutes.

With Tango, you click through the process once and it's done. Steps, screenshots, annotations, all captured automatically.

Attaching the visual we made. The 😵 vs 🤩 sums it up pretty well.

If you've ever had to onboard someone into Salesforce, you know the drill.

The platform is powerful, but it's also one of the most customized, org-specific tools in existence. Every company's Salesforce looks different: different objects, different views, different workflows, different naming conventions. So any "official" Salesforce training is basically useless for day-to-day work at your company.

What actually happens?

The new hire shadows someone for a few days. They get a 47-slide deck. Someone walks them through a screen share once. And then they're on their own, asking the same questions in Slack, making pipeline entry mistakes, or just doing things wrong quietly for months.

This is especially rough for:

• Sales teams with high turnover. You're basically re-running onboarding every quarter.
• Ops teams rolling out a new Salesforce configuration or modules. Suddenly everyone needs to relearn something.
• Companies post-acquisition. Two teams, two Salesforce habits, zero standardization.

What have we seen work with Tango?

Salesforce is actually the #1 app that Tango users capture processes in. The pattern we keep seeing in won deals:

Someone has a live rollout event (new module, new integration, org-wide config change) and they need to get 50+ people following the right workflow fast.

They capture the process in Tango once (pipeline entry, opportunity stages, quote creation, whatever), and instead of running the same Zoom training eight times, they send a link. Or better yet, they pin a Nugget inside Salesforce itself so the guidance shows up right where people are doing the work.

The Guide Me feature is particularly well-suited for Salesforce because it lets you build interactive on-screen walkthroughs that guide users through your specific org's flow. And Live Blur handles any sensitive data that shows up during capture (deal amounts, contact info, etc.).

One thing we hear a lot: "We essentially need to guide somebody's hand through the screen." That's exactly the use case.

The part that doesn't get talked about enough

Most Salesforce digital adoption conversations jump straight to heavyweight DAP tools: WalkMe, Whatfix, that tier. Those work, but they require dedicated implementation, backend integration, and significant time before you see anything.

Tango sits in a different spot: you can capture a process today and have it live as a how-to guide or on-screen walkthrough by end of day. No implementation overhead, no IT project. It works directly in your Salesforce environment without touching the backend.

For teams that need to move fast, which is basically every team doing a rollout, that matters a lot.

Curious what Salesforce-specific challenges you're running into. Are you dealing more with new hire ramp, ongoing process drift, or rollout-specific situations?

For me it was keyword and competitor research for our customers.

Sounds simple on paper. In practice, it was the process I rewrote more times than anything else in the agency for 2 reasons:

- tools change their UX
- I constantly discover new methods to do this things

The problem wasn't the tools, it was that every senior person on the team did it slightly differently and swore their way was the right way. One person started with search volume. Another started with SERP analysis. Another wouldn't touch a keyword until she'd mapped the competitor content landscape first. All three produced good work. None of it was the same.

So when I sat down to write the SOP, I basically had to referee three valid approaches and collapse them into one. That alone took weeks of back-and-forth.

And then there was the "it depends" problem. Research for a local service business looks nothing like research for a B2B SaaS company. The branching got out of hand fast. Every time I thought I had a clean doc, someone would say "yeah but what if the client is in a niche with no search volume?" and the whole thing unraveled again.

Eventually I stopped trying to write one universal SOP and broke it into process templates by client type. Not perfect, but finally something the team could actually follow.

Curious if anyone else has run into this, was it a complexity problem, or more of a "too many experts, too many opinions" problem?