A new hire opens Salesforce for the first time on a Monday morning. By lunch, they have forgotten the name of the button they were shown at 9:15, rediscovered it at 10:40, lost it again when the tab reloaded, and finally asked a colleague on Slack — who was in a meeting. This is not a training failure. It is cognitive load, and it is the default experience of learning any modern SaaS tool. This post walks through what the research actually says, why the product-tour industry exists (and where it falls short), and what an on-demand voice assistant changes about the dynamic.
What cognitive load means in SaaS
The term comes from John Sweller’s 1988 paper on cognitive load theory, originally developed to explain why conventional problem-solving approaches made learning harder, not easier. The model distinguishes three kinds of load on working memory: the intrinsic difficulty of the material itself, the extraneous load caused by how it is presented, and the germane load that actually builds schemas in long-term memory. Working memory has a small, well-documented capacity. When extraneous load consumes it, germane load starves — which is a technical way of saying the user never learns the tool, just survives it.
Modern SaaS is an extraneous-load machine. A typical CRM dashboard has dozens of nested navigation levels, tab systems, contextual menus, and feature flags that vary by seat. None of that is the work the user actually came to do. It is the scaffolding around the work, and every minute spent on it is a minute not spent closing a deal, answering a ticket, or approving an expense. The same principle applies to ERP suites, project management tools, HR platforms, and analytics dashboards. The intrinsic task (log a call, route a ticket, reconcile an invoice) is often simple. Finding where to do it is not.
The where-is-the-button problem
The scale of this problem is not anecdotal. According to BetterCloud’s 2025 State of SaaS report, the average organisation runs roughly 106 SaaS applications — down slightly from 112 the year before, but still an enormous surface area for any one employee to master. Few people are expected to use all of them, but a cross-functional role (a marketing ops manager, a customer-success lead, a recruiter) will routinely touch fifteen to thirty of them in a single quarter, each with its own UI conventions, its own keyboard shortcuts, and its own feature velocity.
Feature velocity is the quiet killer. Even if a user learns a tool well, the vendor ships updates every sprint. Buttons move. Menus are renamed. The “export” function migrates from the toolbar to a three-dot overflow and then to a slide-out panel. Documentation is updated on a lag; internal wikis are updated even later; Loom recordings go stale the day after they are shared. The user’s mental map of the tool is constantly being invalidated by forces outside their control.
The symptom is what teams call “SaaS complexity fatigue” — the low-grade exhaustion of switching between tools, reorienting every few minutes, and losing confidence in one’s ability to keep up. It is one of the reasons tool adoption plateaus at a fraction of purchased seats, why feature usage concentrates on the top three to five capabilities of any given platform, and why so much enterprise software is quietly underused despite being contractually in force.
Walkthroughs vs. on-demand help
A whole industry formed around this problem. Pendo, WalkMe, Appcues, Userpilot, Userflow, and others offer product-tour and in-app-guide platforms: a content team authors tooltips, modals, and multi-step walkthroughs that overlay the target SaaS and guide users through key tasks. These are serious products, widely deployed, and for first-touch onboarding they work. A well-authored tour for “create your first deal in HubSpot” is measurably better than a wiki page.
Two structural limits apply to any authored-tour approach, regardless of vendor.
- Authoring cost. Every tour is content that a human has to write, maintain, localise, and retest whenever the target UI changes. For a tool your team uses heavily, that cost is justified. For the long tail of fifteen to thirty tools per role, it is not — so in practice, tours cover a small fraction of the SaaS surface an employee actually encounters.
- Scripted path assumption. A tour knows the happy path its author anticipated. When the user’s question is “where is the field for VAT exemption on a European invoice?” — a question the tour author never considered — the tour cannot help. It can only replay its pre-recorded paths.
On-demand assistance inverts the model. Instead of the vendor predicting questions and scripting answers ahead of time, the user asks a question in the moment and receives a targeted response about the specific page they are on. No authoring. No pre-recorded flows. The cost of adding a new SaaS tool to the coverage set is roughly zero, because the assistant does not need tool-specific content to begin with — it perceives whatever page it is pointed at.
The two approaches are complementary more than competitive. A well-scripted tour is still the right answer for a high-value, repeated onboarding path (“your first week in HubSpot”). On-demand assistance is the right answer for the long tail of questions that no one thought to script — which, in a 106-app enterprise, is where most of the cognitive load actually lives.
Why voice plus pointing changes things
Reading a doc to find a button is itself a cognitive-load tax. The user has to switch contexts out of the target SaaS, read prose, convert prose into a mental picture of where the button is, switch back, and reconcile the mental picture with the real UI — which, as established, may have moved since the doc was written. Watching a Loom is slightly better for pattern recognition and significantly worse for time-to-answer; the user is forced into the recording’s linear pace and rarely gets to the exact second they need.
Voice plus visual pointing compresses all of that into one gesture. The user speaks their question in the tool; the assistant answers in natural speech; a halo lands on the exact DOM element the answer is about. Three things happen at once that do not happen with docs or Looms.
- No context switch. The user never leaves the page they are trying to use. Attention stays on the target SaaS; working memory is not repeatedly flushed.
- Answer localised in space. “The export button is in the top-right, third icon” is a sentence that a user still has to decode. A halo on the actual pixel is pre-decoded. The translation from language to coordinate happened inside the assistant, not inside the user’s head.
- Answer localised in time. Voice answers arrive in the two to three seconds after the question. A Loom asks for four minutes and hopes the right second is in there.
This is also where cognitive accessibility overlaps meaningfully with general usability. The W3C’s Cognitive Accessibility work — and the guidance in WCAG 2.2 — treats predictability, clear navigation, and input assistance as first-class requirements, not nice-to-haves. An assistant that always answers the same way, always points to the same element for the same question, and never forces the user to re-read a paragraph, fits that brief directly. The users who benefit most from reduced cognitive load are not only people with diagnosed cognitive or learning differences; they are also tired new hires, context-switching managers, and anyone asked to use a tool they did not choose. For a related angle on accessibility, see our earlier post on AI tools for low-vision web users.
A framework for evaluating cognitive-load aids
If you are choosing between tours, docs, video, AI sidebars, and voice assistants for your team, three dimensions separate the credible options from the noise.
- Acquisition cost. What does it take to get coverage for one more tool, one more workflow, one more edge case? A tour platform asks for content authoring per path. A sidebar chat can answer about any page but often requires setup per workspace. An on-demand voice assistant that reads the DOM itself asks for essentially nothing per tool — install once, works everywhere.
- Maintenance cost. What happens when the target SaaS ships a redesign? Authored tours break and need to be rewritten. Doc pages go stale. Loom recordings need re-shooting. An assistant that perceives the live page on demand survives redesigns without intervention, because it never memorised the old layout in the first place.
- Stickiness. Does the aid build the user’s mental model over time, or does it create a dependency that never resolves? A good aid degrades its own usage curve: as the user learns, they ask fewer questions, not more. A tour that greets the same user with the same modal every month is a sign the tour is not actually teaching. Measure declining question volume per user, not total question volume, as the success metric.
There is a fourth dimension, relevant mostly for enterprise buyers: the privacy envelope. Anything that sits over a corporate SaaS potentially sees sensitive data. The honest question to ask a vendor is which permission model the extension uses and when it captures. Broad-host permissions that read every page you visit are a different risk class from a push-to-talk model that only captures on an explicit key-press. We covered this in depth in our overview of agentic browser assistants; the short version is that push-to-talk plus activeTab is roughly the floor of what a cognitive-load aid should ask for on a corporate machine.
Where Clicky fits — the Team tier case
Clicky is a push-to-talk Chrome extension. Hold Alt, ask a question about whatever SaaS tab is in front of you, and it answers aloud while pulsing a halo on the exact DOM element the answer refers to. No walkthroughs to author. No per-tool integration. No server-side memory between sessions. For the cognitive-load scenario described throughout this post, four product choices matter.
- No pre-authored tours to maintain. Clicky does not require a content team to script paths ahead of time. The assistant reads whatever page is open and answers about it. Your coverage set is every SaaS your team already uses — not a curated subset somebody wrote tours for.
- Works on any SaaS your team already has. Salesforce, HubSpot, SAP, Notion, Jira, Workday, NetSuite, Concur, a custom internal admin panel — none of them need integration work. Install the extension; it works on all of them on day one. The marginal cost of adding a new tool to your stack is zero training cost, not a tour-authoring project.
- Voice plus pointing rather than reading. Answers arrive in the two to three seconds after the question, spoken aloud, with the relevant element visually highlighted. Users stay in the target tool; working memory is not flushed by a context switch to a doc or a video.
- Narrow permission footprint. Clicky uses Chrome’s activeTab permission and session-only memory. The extension sees a page only at the moment you explicitly invoke it — never in the background. For corporate security reviews, this is materially different from broad-host chat sidebars that read every page continuously. Full details live on our privacy page.
The Team tier is designed around this exact scenario: one buddy for every tool your team uses, across every SaaS in the stack, without authoring overhead. Pricing and seat structure are on the pricing section of the landing page. For teams whose tools include internal or custom-built applications, a For Software tier lets product teams embed the same assistant directly into their own interface — same perception model, same voice plus pointing, applied to the software you ship rather than only the software you buy. If you want to see the mechanism first, see how Clicky works.
Frequently asked questions
Is this a replacement for our existing onboarding program or tour platform?
No, and we would be careful about anyone who claimed otherwise. A scripted first-week onboarding in your highest-value tools is still the right shape for structured learning objectives. An on-demand voice assistant is the right shape for the thousand unscripted questions that come up after onboarding ends — the long tail of “where is this” and “what does this field mean” moments that no tour author ever covered. Run them together.
Does it work on internal or custom-built applications?
Yes. Because the assistant perceives whatever page is in front of it via screenshot and DOM rather than through a pre-built integration, internal admin panels and custom-built apps are treated the same as public SaaS. For teams that want a branded, embedded version inside their own software, the For Software tier ships an SDK for that use case.
How do you handle sensitive data on a corporate machine?
Three mechanisms: push-to-talk (the microphone is strictly off unless the Alt key is held), activeTab permission (the extension reads a page only when you explicitly invoke it, never in the background), and session-only memory (nothing persists server-side between sessions by default). This does not remove the need for a security review, but it changes which questions the review should focus on. Details on the privacy page.
How should we measure whether it is actually working?
The two useful metrics are time-to-first-successful-action on a tool — how long from login to completing the task the user came to do — and question volume per user over time. A good cognitive-load aid lowers the first and then lowers the second, as users learn and stop needing to ask. If question volume stays flat across months, the aid is a crutch, not a teacher. If it declines per user while total usage grows with headcount, the aid is doing its job.
Next post in the series: hands-free browsing for users with motor impairments — what changes when the Alt key itself is not a reliable input, and which voice-first designs hold up under that constraint.