There are three useful ways to make Fin more proactive, each requiring more setup than the last.

Before getting into the levels, here is the difference it makes in practice:

Without session context

User: I can’t change my plan.

Fin:  Here’s how to change your plan: [help article link]

With session context

Internal note: User visited /billing, selected Pro plan, 
submitted checkout, hit a payment validation error.

User: I can’t change my plan.

Fin:  It looks like the payment step didn’t complete — the card validation failed.

      Try re-entering your card details or use a different payment method.

What Fin depends on

Fin is not a static chatbot. Its behavior depends on the sources you give it and the instructions you configure.

You can make it answer from help center articles, product docs, internal notes, and other structured inputs. You can also decide which sources matter most in a given flow, which documents should be treated as primary, and how Fin should respond when sources conflict.

For example, billing docs might be primary inside a checkout flow, while general onboarding docs are secondary.

The limitation is usually not the model. It is what Fin can see. If Fin can only see the user’s message and your docs, it can give a good generic answer. If the conversation also includes the user’s product activity, workflow, and recent actions, Fin has a better starting point.

The two common Intercom setups

Most teams start in one of two places.

Some configure Fin mostly inside Intercom: Workflows, routing, articles, canned replies, and outbound messages.

Others take a more developer-led approach and connect Intercom to internal APIs, user data, and custom logic.

Both are useful, but neither automatically gives Fin live product context.

Level 1: URL and page targeting in Workflows

The simplest way to make Fin proactive is using Intercom’s Workflows to trigger a message when a user visits a specific page. No custom events, no API calls, just URL rules and a workflow.

In the Intercom workflow builder, set your trigger to “Customer visits a page” and add a page rule:

• URL contains /pricing: triggers for any URL with /pricing in the path

• URL starts with https://app.yourproduct.com/billing: targets all billing subpages

• Exact match: triggers only on one specific URL, including query parameters

You can also layer in time on page as a condition. For example: trigger only if the user has been on /pricing for more than 60 seconds. That is already better than firing the chatbot the second someone lands on a page.

At the end of the workflow path, add a “Let Fin answer” step. When the user replies to the workflow message, Fin takes over and handles the conversation, pulling from your help docs, product articles, and system prompt instructions.

This gives you basic location-aware and timing-aware support with no code. The limitation is that the workflow is still based on a page rule. Fin knows where the user is, but not much about what they did before or after that page view.

Level 2: Event-based triggers

If you are tracking custom events in Intercom, you can use them to trigger messages, a step closer to behavior-based proactivity.

Track events via the JavaScript API:

window.Intercom(’trackEvent’, ‘selected-plan’, {

  plan_name: ‘Pro’,

  billing_cycle: ‘annual’

});

Once that event is tracked, you can create an outbound message in Intercom that fires every time the event is recorded. In the message rules, set “When” to your event, then configure frequency to avoid over-messaging. For example, at most once per hour per user.

You can also filter by event metadata. For example, only trigger the message if billing_cycle is annual, or layer in a “Where” rule like Current URL contains /checkout.

To keep Fin in the loop, add “Let Fin respond” as a follow-up action on the outbound message. When the user replies, Fin picks up the thread.

This is better than URL targeting. You are reacting to things users actually did, not just where they are.

But there is an important limitation: event-based messages use events as triggers, not as context.

You can manually define an event like selected-plan and trigger a message when it happens. But that does not mean Fin understands the sequence of events that led up to the conversation.

The event can start the conversation, but it does not become part of Fin’s reasoning unless you connect that event data back into the conversation as context.

That is the difference between event-based triggers and real-time session context.

Level 3: Real-time session events

The goal is not just to trigger a chatbot response from an event. The goal is to make the user’s recent product activity available as context inside the Intercom conversation.

That means connecting session events as a data source for the conversation, not just using them as one-off triggers.

You do not need every raw event. You need the actions that help Fin or the support team understand what the user was trying to do, what happened before they opened chat, and where the workflow broke down.

The pattern has four parts:

1. capture product events

2. link the product session to the right Intercom conversation

3. write useful activity into the conversation as internal notes

4. summarize and clean up older notes so the thread stays readable

This is where a tool like Autoplay can help. Autoplay provides an SDK for sending real-time product activity into chat and support tools. For Intercom, it handles the session linking, buffering, internal note writing, redaction, and summarization.

The pipeline looks like this:

Product events (PostHog)

→ Autoplay links the session to an Intercom conversation

→ Autoplay writes internal notes into the conversation thread

→ Those notes become context inside the Intercom conversation

Internal notes are the bridge. They let you put product activity into the Intercom conversation without showing it to the user. The support team can read them, and Fin can use that context depending on how your Intercom workspace is configured.

In practice, you should write only the product actions Fin or the support team need, not raw sensitive input values.

1. Capture product events

You need a stream of product activity: page views, clicks, form submissions, errors, and workflow events.

Autoplay uses PostHog-compatible capture for this. You add the snippet to your frontend, identify the user after login, and pass the fields Autoplay needs to connect that product session back to Intercom.

2. Link the product session to the Intercom conversation

Product events only help if they end up in the right thread.

Autoplay uses Intercom webhooks to know when a user starts or replies to a conversation. The key webhook topics are:

conversation.user.created

conversation.user.replied

Once Autoplay links a product session to an Intercom conversation, that mapping is kept stable so later events continue going into the same thread.

3. Write internal notes into Intercom

Once the session is linked, Autoplay writes product activity into the conversation as internal notes.

Those notes are visible to the support team, but not to the user. They give Intercom a live picture of what the user is doing in the product, for example:

[1] User clicked Sign up button on the pricing page

[2] User clicked Confirm plan button on the checkout page

[3] User submitted payment form on the checkout page

In practice, you should only write the product actions Fin or the support team need, not raw sensitive input values.

4. Buffer events before the conversation is linked

Sometimes product events arrive before Autoplay knows which Intercom conversation they belong to.

In that case, Autoplay buffers the actions. Once the session is linked to a conversation, the buffered activity is flushed into the right thread.

5. Summarize and clean up older notes

Raw action notes are useful, but you do not want the Intercom thread to become a wall of events.

Autoplay can summarize the session after a configurable threshold of actions and redact older raw notes. The summary is written back into Intercom as a cleaner internal note:

The user navigated to the pricing page, selected the Pro plan,

submitted the checkout form, and hit a payment validation error.

They later returned to billing settings.

The summarization step is separate from Fin. Fin and the support team then have that summary available inside the Intercom conversation, depending on how your workspace is configured.

For the full implementation, including the snippet, webhook setup, session mapping, note writing, redaction, and summarization, see the Autoplay Intercom integration guide.

What this changes

With session notes in the thread, Fin and the support team have context before the user explains the problem.

If someone opens chat and asks “why can’t I change my plan,” the conversation already has a note showing they visited billing, selected Pro, submitted checkout, and hit a payment validation error.

Instead of asking the user to retrace their steps, the team can read the session summary and pick up from there.

Picking the right level

Most teams do not start with real-time session context, and they do not need to. URL and event triggers cover a lot of ground and are worth setting up properly before adding anything more complex.

But if your support team regularly spends time asking users to retrace their steps, or if Fin is giving technically correct answers that miss the actual workflow the user is stuck in, that is a signal that session context would help.

The Intercom docs for URL targeting, event-based messages, and letting Fin follow up after Workflows are good starting points for the first two levels.

If you want to add the real-time layer, the Autoplay Intercom integration guide walks through the implementation: webhooks, session mapping, note writing, and summarization.

Subscribe now

Share

That makes this a useful moment to explain a design choice that sits underneath it: why our real-time architecture started with PostHog.

Autoplay is not a reporting layer. It is infrastructure for turning live product behavior into model-readable context. The SDK is the public interface to that system. You connect your app, stream real-time user activity into your service, and receive typed payloads that can be embedded, stored, retrieved, and passed into agents or copilots. In our docs, that flow is explicit: browser activity enters the Autoplay connector pipeline, gets extracted, normalized, and optionally summarized, then arrives over SSE or push webhook as typed payloads your application can use directly.

That architecture needs a specific kind of event layer.

It needs broad browser-side capture with low frontend burden. It needs identity and session continuity. It needs an event model that is simple enough to ingest at scale but expressive enough to carry useful context. It needs a clean way to route that stream into your own infrastructure in real time. It needs enough structure that downstream systems can reason over it programmatically. And it needs pricing that makes dense behavioral capture practical, not something you immediately start trimming.

Those are the reasons we started with PostHog.

That phrasing matters. We do plan to support other analytics layers over time. But when we were building the first version of this architecture, PostHog was the cleanest fit for the problem in front of us. It gave us the best starting point for building a real-time behavioral backbone that could power agents, copilots, memory systems, and retrieval pipelines, not just dashboards.

The architecture we actually run

In our standard setup, a customer installs posthog-js in the frontend, initializes it with their Autoplay API key, attaches a product_id, and identifies the user again after login with their application user ID and optionally email. That gives us the behavioral stream, the routing key, and the identity bridge we need for session and conversation linking. Our quickstart also uses a two-minute session idle timeout so the stream stays aligned with how we package live context downstream.

From there, we configure a PostHog webhook destination pointed at the customer’s Autoplay connector. That is the important boundary in the system. Before that point, you have events. After that point, you have context.

Autoplay takes the incoming stream and turns it into something agent systems can actually use. We extract raw browser activity into normalized actions, label those actions in natural language, group them into sessions, and optionally summarize the session into compact prose. The SDK then exposes that as typed ActionsPayload and SummaryPayload objects over SSE or push webhook. Those payloads are designed to flow straight into vector stores, memory systems, copilots, and RAG pipelines.

The path looks like this:

1. posthog-js captures browser activity.

2. PostHog ingests the events and attaches user and session context.

3. PostHog forwards selected events to the Autoplay connector.

4. Autoplay extracts, normalizes, labels, groups, and optionally summarizes the session.

5. autoplay-sdk consumes the resulting stream over SSE or push webhook.

6. Your service embeds that context, writes it to memory or retrieval infrastructure, and passes it into a model.

7. The model decides whether to stay silent, answer reactively, or trigger proactively.
   
   

That is the architecture we use ourselves. But the more useful point is that it is also a pattern other teams can adopt. If you want support systems that know what the user was doing before they opened chat, copilots that react to real workflow state, or memory systems that update from product behavior instead of only from text conversations, this is the kind of event backbone you need.

Why the event model mattered

The core unit in PostHog is an event: a user or distinct_id, a timestamp, an event name, and a JSON-like property blob. Those properties can include text, booleans, numbers, dates and timestamps, arrays, and nested objects. That sounds basic, but it is exactly what made the model useful outside dashboards. It is flexible enough to carry product-specific context, and typed enough to stay understandable as the system grows.

That flexibility also matters operationally. Teams can define event schemas, manage event definitions, and group properties so structure stays consistent and discoverable over time rather than drifting into a mess of ad hoc payloads. Events can also be enriched with user properties, group properties, and custom metadata, which matters because downstream analysis is rarely based on a naked click stream. Useful systems usually need organization-level context, user state, workflow identifiers, route keys, and product metadata attached to the underlying behavior.

That is what made PostHog a strong starting point for us.

If you are building agent systems, the raw requirement is not “have events.” It is “have events that can be turned into state.” You need enough flexibility to attach product IDs, route keys, workflow hints, or metadata without fighting the schema. You need enough structure that your application can reason over the stream programmatically. And you need enough consistency that models are not being fed an ever-changing mess of telemetry. PostHog gave us a strong base layer for that, and then Autoplay does the second half of the work by turning that event stream into typed actions and readable session summaries.

Why capture quality mattered

If you are trying to build on top of behavior, instrumentation burden matters as much as event quality.

PostHog’s web SDK automatically captures pageviews, pageleaves, clicks, input changes, and form submissions for common interactive elements by default. That meant teams could get broad behavioral coverage quickly rather than spending weeks manually instrumenting every workflow before they could test anything useful. For our use case, that mattered because the captured stream is not the final product. It is the substrate we transform into agent context. The faster you can get a high-coverage stream, the faster you can start turning real behavior into something your models can use.

This is one of the biggest reasons it made sense as our starting point. A product team, support engineering team, or platform team can start with the same behavioral stream they already want for analytics, then use that same stream to power runtime systems. That means fewer duplicate SDKs, fewer competing schemas, and less drift between what the dashboard says happened and what the copilot thinks happened.

Why routing mattered

A lot of analytics products are good at collecting events and surfacing them in charts. That is not the same as being comfortable in the middle of a live product system.

For our use case, the event layer had to be adjacent to runtime. It had to let events move outward in real time into our own pipeline, not stop inside a reporting product. PostHog’s platform explicitly distinguishes between public capture endpoints and private query endpoints, and supports real-time destinations and webhooks in its broader product surface. It also supports transformation and enrichment patterns at ingestion time, which helps keep downstream data clean and structured before it reaches the systems that actually consume it.

Its public POST-only endpoints, including event capture at /i/v0/e, are not rate-limited, while private authenticated endpoints are rate-limited separately. For many analytics endpoints, the documented limits are about 240 requests per minute and 1,200 per hour. The query endpoint allows up to 2,400 per hour. Other private read and write APIs are capped around 480 per minute and 4,800 per hour per API key.

That separation is exactly what you want when the critical path is capture and forwarding, not dashboard queries.

In other words, if you are building agents, copilots, or internal systems that need the behavioral stream while the session is still alive, the shape of the API matters. You do not want the useful path to depend on a reporting endpoint. You want ingestion to feel like infrastructure. PostHog was a strong fit for that, which is why we started there.

I am also deliberately being precise here on latency. We treat the stream as effectively live in practice, which is what matters for our architecture. I am not making a hard benchmark claim here about exact milliseconds, and I am not claiming exact queue behavior for other vendors without controlled benchmarks. The important point is architectural: PostHog was designed in a way that made real-time capture and routing practical for our first version.

Why sessions and replay mattered

Single events are useful. Real user workflows are sequences.

PostHog supports both event capture and session replay. That mattered because teams often need both views at once: the granular stream for live state, and the session-level view for validating friction, detours, hesitation, and workflow breakdowns.

Session recordings are a separate unit from standard analytics events. They are stored and priced per session or recording, not per event. They are also more expensive per item than standard analytics events, which makes sense because they are a denser resource. PostHog’s pricing treats session replay as a separate resource, with a free tier and then tiered per-recording pricing beyond that. Product analytics events are priced separately, starting at roughly $0.00005 per event after the first 1 million monthly events, which are free.

Architecturally, that distinction is useful.

The high-volume event stream is what powers real-time state and downstream decisions. Session replay is the denser, slower path you use to inspect complete workflows, validate behavior, and build better models of how users actually move through the product. It helps you see detours, friction points, hesitation, and navigation patterns that matter when you are trying to understand real workflows instead of isolated clicks. If you care about product-aware AI, having both event-level and session-level data available in one stack is a real advantage.

Why pricing was part of the technical decision

Pricing is not a procurement detail here. It shapes what you can build.

If your event layer is too expensive, teams start deleting the very signal that makes behavioral systems useful. PostHog’s usage-based pricing keeps the basic model simple: the first 1 million product analytics events per month are free, then pricing starts at $0.00005 per event and decreases with scale. That is about $50 per 1 million events at the starting paid tier. Session replay has its own free tier and tiered pricing by recording, and those recordings are priced separately because they are a different resource than standard analytics events.

That mattered for us, but it also matters for anyone experimenting with real-time support or product-aware copilots. You need enough behavioral density to make the model useful. If every additional event feels like a billing risk, the system gets blind very quickly.

It also means startups and early-stage teams can get a meaningful amount of signal before the event layer becomes a real cost center. If you are capturing tens or even hundreds of thousands of events per month, you are still working in a pricing model that feels like infrastructure, not something that forces aggressive under-instrumentation on day one.

Where the SDK fits in

This is also why we launched the SDK in the shape we did.

autoplay-sdk is not another analytics SDK. It is the interface to the transformed stream. It consumes the connector over SSE or push webhook and hands your application typed Python objects, not raw JSON blobs. ActionsPayload gives you session ID, user ID, product ID, ordered actions, counts, and an embedding-ready .to_text() method. SummaryPayload gives you a prose version of the session when you want compact context instead of a full action list. The SDK also supports async and sync clients, push and pull delivery, Redis-backed buffering, and per-session concurrency isolation, so a slow downstream job in one session does not block another.

A simple frontend setup looks like this:

import posthog from ‘posthog-js’

posthog.init(’YOUR_AUTOPLAY_API_KEY’, {

    api_host: ‘https://us.i.posthog.com’,

    person_profiles: ‘identified_only’,

    session_idle_timeout_seconds: 120,

    loaded: (posthog) => {

        posthog.identify(posthog.get_distinct_id(), {

            product_id: ‘YOUR_AUTOPLAY_PRODUCT_ID’,

        });

    },

})

// after login

posthog.identify(user.id, {

    product_id: ‘YOUR_AUTOPLAY_PRODUCT_ID’,

    email: user.email,

})

And then the downstream service consumes the live stream:

import asyncio

from autoplay_sdk import AsyncConnectorClient

STREAM_URL = “https://your-connector.onrender.com/stream/YOUR_PRODUCT_ID”

API_TOKEN = “unkey_xxxx...”

async def on_actions(payload):

    text = payload.to_text()

    embedding = await embed_api.create(input=text)

    await vector_store.upsert(id=payload.session_id, vector=embedding)

async def on_summary(payload):

    text = payload.to_text()

    await vector_store.upsert(id=payload.session_id, vector=await embed(text))

async def main():

    async with AsyncConnectorClient(url=STREAM_URL, token=API_TOKEN) as client:

        client.on_actions(on_actions)

        client.on_summary(on_summary)

        await client.run()

asyncio.run(main())

The point is not just that this works. It is that customers do not need to build the interpretation layer themselves. PostHog captures the live behavioral stream. Autoplay turns it into typed, LLM-ready context. The SDK makes that context easy to consume.

That is useful whether you are building with Autoplay specifically or thinking about the general pattern. The better the event backbone is, the less custom interpretation code you need to write yourself.

What this enables in practice

This is not just good for us. It is useful for a lot of teams working close to product behavior.

A support team can build a copilot that already knows what the user was doing before they opened chat.

A product team can build a proactive assistant that notices repeated no-progress behavior and intervenes at the right moment.

A growth or onboarding team can track whether someone has actually completed a workflow, not just visited a page.

An engineering team can update user memory or retrieval systems from real behavior instead of only from text inputs.

These are the kinds of use cases our docs are built around: real-time events first, then memory, then golden paths, then trigger logic that decides when to proactively help and when to stay quiet.

The key point is that they can all share the same behavioral stream.

That is the real architectural benefit. You do not need one telemetry layer for analytics and a second completely separate telemetry layer for runtime AI. PostHog gives you the capture, identity, sessioning, and event backbone. Autoplay turns that stream into typed, model-readable context. The SDK exposes it in a form developers can use directly.

The real reason we started with PostHog

The shortest version is this:

We did not need a tool that was only good at telling us what happened last week.

We needed a tool that could sit in the loop between user behavior and system response.

That meant the event layer had to capture enough detail without heavy manual instrumentation, preserve identity and session continuity, support a flexible but typed data model, allow enrichment with user, group, and product context, route data outward in real time, remain open to programmatic consumption, support both events and sessions, and stay affordable enough to use as infrastructure.

PostHog had that combination.

That does not mean it is the only analytics layer we will ever support. It means it was the right place to start.

At Autoplay, that is what let us take a live behavioral stream, turn it into typed LLM-ready context, and use it to power agents and copilots in the moment. But the more general point is this: if you want product data to do more than describe the past, you need an event backbone that is comfortable powering systems outside the dashboard too.

That is why we started with PostHog. And that is why the setup is useful for our customers as well.

Subscribe now

Leave a comment

So we built a pipeline to go deeper, ingesting sessions at scale, extracting structured intent signals: what workflows users were attempting, which tasks they completed, where they stalled. We built TERRA, a framework to understand the relationship between user actions and the ideal “golden path” through a product, model completion rates per workflow, and understand intent at the session level.

Then the obvious question was: why are we only looking at this after the fact?

The Problem With Reactive AI

Most AI copilots wait to be asked. A user opens the chat, types a question, gets an answer. It’s a slightly smarter FAQ, but it misses the majority of users who never open the chat. They hit a wall and quietly leave.

Take a PLG onboarding flow (e.g. SMSPs). New user signs up, no guided tour. They need to connect their Instagram account, upload their media, before they schedule their first post. They reach the auth screen, get confused, click back to the dashboard thinking they’re done. They try to post. Nothing works. First session. Often their last.

Your chatbot has no idea any of this is happening. Your support team can fix it, but only after the user is gone.

What the Data Stack Gets Wrong

You already have the data. LogRocket shows the user left the auth screen after 8 seconds. Amplitude shows a drop-off at onboarding step 3. Segment has a connect_instagram_started event with no completed match.

You know they left, where, and when. But none of these tools know what the user was trying to do, and without intent, goal, and progress, you can’t trigger action. You can’t tell your chatbot to intervene. You can’t send the right email. You just watch the funnel.

The gap isn’t in data collection. It’s in the layer that turns raw activity into something an AI agent can reason over.

Introducing the Autoplay Proactive SDK

Today we’re launching the Autoplay Proactive SDK- streaming what your users are doing, in real time, as clean, structured, LLM-ready context directly into your agents.

Not raw telemetry. Structured payloads: the page the user is on, what they clicked, what they’re trying to accomplish, where they’ve stalled. Autoplay sits between your product and your copilot, it doesn’t replace Intercom or Zendesk, it gives them eyes.

Pull: smarter answers when users ask. User asks “how do I schedule a post?” Without Autoplay, the chatbot returns a generic setup article. With Autoplay, it knows they reached the Meta auth screen 4 minutes ago and left without completing it, and delivers the exact missing step.

Push: intervention before they ask at all. Autoplay detects the missed step the moment it happens and fires your copilot: “It looks like Instagram isn’t connected yet, here’s the one step you need.” User completes the flow. Schedules their first post. Stays.

The Three-Layer Model

The SDK is a progressive build-up. Each layer makes your copilot meaningfully smarter.

Layer 1: Real-time events (available now.) Every user action is captured, processed (extraction → normalisation → optional LLM summarisation), and delivered as a typed payload. Your agent knows what the user is doing right now without waiting for them to describe it.

Layer 2: User memory (coming soon.) A per-user knowledge profile, updated after every session: what they’ve mastered, what’s in progress, what they’ve never touched. Your agent stops suggesting workflows the user already knows and starts surfacing the actual gaps.

Layer 3: Golden paths + knowledge base (coming soon.) Record the ideal journey for any workflow using the Autoplay Chrome extension. Autoplay indexes these in a vector database. At inference time, your agent retrieves the ideal path, compares it to what this user has done, and surfaces the precise next step.

Where the user is now        ← real-time events
What they've already done    ← user memory
Where they should be going   ← golden path from knowledge base
                                       ↓
         copilot surfaces the single most relevant next step

Getting Started

Integration takes minutes.

See our full docs here.

Step 1 — Add the snippet to your frontend

import posthog from 'posthog-js'

posthog.init('YOUR_AUTOPLAY_API_KEY', {
    api_host: 'https://us.i.posthog.com',
    person_profiles: 'identified_only',
    session_idle_timeout_seconds: 120,
    loaded: (posthog) => {
        posthog.identify(posthog.get_distinct_id(), {
            product_id: 'YOUR_AUTOPLAY_PRODUCT_ID',
        });
    },
})

After login, pass the user’s email to enable cross-session identity linking:

posthog.identify(user.id, {
    product_id: 'YOUR_AUTOPLAY_PRODUCT_ID',
    email: user.email,
})

Step 2: Install the SDK

pip install autoplay-sdk

Requires Python 3.10+

Step 3 — Receive your first event

import asyncio
from autoplay_sdk import AsyncConnectorClient

async def main():
    async with AsyncConnectorClient(url=STREAM_URL, token=API_TOKEN) as client:
        client.on_actions(lambda p: print(p.to_text()))
        client.on_summary(lambda p: print(p.summary))
        await client.run()

asyncio.run(main())

Step 4 — Wire it to your copilot

from autoplay_sdk import AsyncConnectorClient, ActionsPayload

async def on_actions(payload: ActionsPayload) -> None:
    suggestion = await your_llm(
        system="You are a proactive product copilot. Suggest one helpful next step. Be brief.",
        user=f"## What the user is doing\n{payload.to_text()}",
    )
    if suggestion:
        await push_to_ui(payload.session_id, suggestion)

client = AsyncConnectorClient(url=CONNECTOR_URL, token=API_KEY)
client.on_actions(on_actions)

payload.to_text() is embedding-ready — pass it into your LLM context, upsert it to a vector store, or use it to trigger any downstream action: email, Slack notification, support escalation with full context attached.

Delivery is available as an SSE stream or push webhook. Both emit the same typed ActionsPayload / SummaryPayload objects.

What You Can Build

Reduce first-session churn. Detect exactly where users stall and trigger a contextual nudge before they leave in-app, chatbot, or email.

Eliminate generic chatbot answers. Every time a user opens support, your agent already knows what they were doing in the product 30 seconds ago.

The reboarding play. User has been on your platform three months but has never opened Analytics. Autoplay detects the gap. Copilot fires: “Want to see your best-performing posts?” Analytics adoption. Upgrade trigger.

Proactive upgrade signals. User hits a limit and starts exploring pricing — Autoplay detects the sequence and triggers your sales motion before they bounce.

Live-context RAG. Embed ActionsPayload events into your vector store in real time for retrieval grounded in what users actually do — not just your docs.

Join the Private Beta

Early access teams get the full SDK, a dedicated connector URL and API token, direct Slack support from us, and early influence on the roadmap.

→ Sign-up to our private beta access

→ Join our Slack workspace — drop a message in #just-integrated after you add the snippet and we’ll get your connector set up same day.

→ Read the docs

What We Believe

The future of AI in software isn’t a chat widget that waits. It’s an agent that knows — what this user is trying to do, where they are right now, what they’ve done before, and what comes next. Everything we’ve built — the session analysis, intent modelling, golden path framework, the pipeline from raw DOM events to LLM-ready context, was pointing here.

We think this changes the economics of onboarding, support, and activation. If you’re building AI-powered products and want your agents to actually know what’s happening, come build with us.

Built in New York. Questions? sam@autoplay.nyc

Subscribe now

The agent’s problem wasn’t reasoning, or understanding my prompts. It was that it used Airbnb badly. It treated the search like a structured query: enter constraints, get results, pick the best one. What I actually did looked nothing like that. I was moving around the map, zooming in and out, opening listings, closing them. I’d look at three places on the same street and decide the street felt off, shift the map slightly, start again. Photos did most of the work. You can tell fast if a place will feel cramped, if the light is bad, if it’s one of those apartments that looks good in the first shot and gets worse after. None of that is in a filter.

There’s also a constant re-ranking happening that you’re not conscious of. You see something slightly better and everything before it drops. You revisit a listing you’d dismissed and it moves up because the alternatives got worse. The agent had no access to any of that.

To know whether the agent did a bad job, you have to do the task yourself, at which point you’ve already done the job. You could give it better instructions, and send it back. But after 45 minutes of watching it search, who wants to evaluate its results, write new prompts, and send it through the whole process again? You either trust what it came back with, or it’s faster to do it yourself.

My session replay, every click, every listing opened and closed, every time I nudged the map, is a complete record of how the preference formed. It’s not noise, but a decision taking shape in real time, and it’s a better benchmark for evaluating the agent than checking whether it completed the booking. The question is whether it converges on the same kind of place and explores the same parts of the map. The ground truth is the process, not the outcome.

Most agent evaluation misses this. We keep asking “did it finish the task” when the more useful question is “did it make the same moves a good human would make.”

The Airbnb UI is built for humans. Visual, spatial, optimized for comparison. It evolved to match how people actually process and filter information. We moved from databases to spreadsheets to SaaS interfaces because each step was more legible to the way humans think.

For an agent, all of that is overhead. It doesn’t need a map. It doesn’t parse photos the way we do. What it actually wants is closer to a spreadsheet, 800 rows, clean columns, every listing queryable. The agent could reason over it directly without navigating a UI built for someone else.

Are we regressing? Is the right interface for an agentic world just a database with an API? Run a filter algorithm, return ranked results, done. That’s not a new idea, it’s basically what SaaS was before anyone put a visual layer on top of it.

The UI isn’t just a display layer for humans. It’s where intent forms. I didn’t know exactly what I wanted when I started; browsing was how I figured it out. The visual, spatial, comparative experience of Airbnb isn’t a nice-to-have on top of the data. It’s the process by which a vague preference becomes a specific one. Strip it out and you haven’t made the problem simpler, you’ve just removed the mechanism by which the goal gets defined.

The agent working from a spreadsheet would be faster and more systematic and would still pick worse apartments, because it would be optimizing against a goal that was never properly formed in the first place.

So where does that leave browser agents? The question isn’t whether they’ll replace humans doing this kind of task. It’s whether they can participate in the loop that makes the task work. The one where preferences shift in real time based on what you’re seeing, where the UI is doing cognitive work, not just displaying results.

What changes this isn’t better reasoning or better prompts. It’s agents that read UI behavior as signal: which listings got attention, which got skipped, what got revisited, and what got dropped the moment something better appeared, and use that to infer intent in real-time instead of waiting to be told what to optimize for. The UI doesn’t become redundant. It becomes the data source. The session becomes the instruction set.

That’s a different architecture than most browser agents are built on. And it’s why an Airbnb test is more interesting than it looks.

Subscribe now

Share

Most software, on the other hand, behaves like a well-meaning teacher. We smooth the edges, add a bit of animation, pare back the clutter, and assume that if the UI is clean enough, people will figure it out. For simple products, they do. You open a form, click a button, and the software behaves as we promised. The illusion of clarity feels real - until the product stops being simple.

Once a product becomes a real system (multiple roles, tangled permissions, messy data, exceptions, “it depends” logic), the user isn’t just navigating a product anymore. They’re trying to complete a workflow inside a living environment, with all its quirks and resistances.

That’s why so many AI copilots feel brilliant in demos and disappointing in real life. They can speak. They can explain. They can even suggest steps. But they never feel like they’re with you inside the product. They feel like they’re standing outside the room, talking through the door, while you’re inside, trying to keep control of something that’s already moving.

Most software does the opposite: it gives you options before certainty. It makes you hunt for context, then punishes you when you pick the wrong path. Add AI on top, and you don’t fix the problem. You magnify it - because the weakness isn’t the assistant’s language. It’s its blindness to state.

The UI isn’t going away. It’s just going to stop being uniform. People love saying, “Agents will replace UIs.” But I don’t think the UI disappears. I think it stops being static. The endgame isn’t a blank screen where you type commands. It’s an interface that reshapes itself around the moment: what you’re trying to do, what you’ve already done, what your role allows, what your team usually does, and what tends to go wrong at this step.

That’s why UX is more important than ever. It’s no longer just about aesthetics. It’s about the product’s ability to keep you moving when reality gets messy. And in any real system, reality will always be messy.

Here’s why copilots keep getting complex products wrong: in rich, evolving software, there is no single “correct workflow.” There are workflows, plural. One person’s happy path is another person’s exception. One team’s process is another team’s workaround. Power users don’t follow the docs. They discover patterns and combinations that the documentation never imagined.

So when a copilot is trained only on text (help center pages, macros, old docs, forum posts), it makes a quiet, dangerous mistake: it confuses “what’s written down” with “what’s possible.” That’s where you hear the false negative: “It can’t be done.” Not because the product can’t do it, but because the assistant can’t see the product. It can’t see your permissions, your UI state, the earlier steps you’ve already taken, or what just failed. It’s reasoning with a blindfold on.

And when you build “agentic automation” on top of that, the problem becomes personal. Now the agent is doing things that you, the user, have to debug inside a system you may not fully understand.

If copilots are going to work inside real products, they need to be grounded more like a cockpit than a manual. They need to quietly, constantly, and in real time answer questions like: What is the user trying to accomplish right now? Where are they in the workflow? What’s on screen and available to them? What state is the system in? What just changed? Are they progressing, exploring, or stuck?

Everyone rushes to the chat UI because it’s visible. But chat is only useful when it sits on top of product understanding. Otherwise, it’s just a very polite search box, pretending to be a companion.

For years, “good software” meant fewer clicks. The next era is about fewer moments of uncertainty. The most valuable products won’t be the ones that answer questions faster. They’ll be the ones that reduce the need to ask in the first place - by recognizing intent, tracking where you are in the workflow, and surfacing the next meaningful step at the moment it matters.

The interface becomes personal, not because it’s pretty, but because it’s aware. Aware of your context, your history, your role, and your confusion. And that’s the real shift: not conversation replacing clicks, but software finally meeting users where they are - instead of where the docs assumed they should be.

Leave a comment

Subscribe now

What stood out quickly was how the Leyton and Leyton CognitX teams operate. They are not trying to fit their business into SaaS tools. They build internal systems that match how they work, then start replacing parts of those workflows with agents.

This is a pattern I keep seeing. Strong teams move toward control. They want systems that reflect their workflows, not tools they need to work around. Once that is in place, the next step is obvious. Automate parts of the workflow.

The interesting part is where things break.

Building an agent is no longer the hard part. You can get something that looks good in isolation without much effort. The issue shows up when the agent runs inside a real product.

Internal tools are not clean environments. Permissions change. UI changes based on role and state. Data is inconsistent. There is rarely one correct path through a workflow. What looks like an edge case in theory happens all the time in practice.

So you end up with agents that can reason, but still make bad decisions. Not because they are incapable, but because they are missing context.

We kept coming back to a small set of questions. If an agent cannot answer these, it cannot be reliable.

What is the user trying to do.

Where are they in the workflow.

What is on the screen right now.

What state is the system in.

Is the user stuck or progressing.

Without this, the agent guesses. Sometimes it gets it right. Often it does not.

This is where Autoplay fits.

We focus on connecting behavior to intent and workflow context in real time. Mapping actions to tasks. Tracking how users move through workflows. Understanding what is happening on the screen during execution. Detecting when someone is hesitating or drifting.

That changes how an agent behaves. It stops reacting to isolated inputs and starts responding to what is happening in the product.

The week mattered because the conversations stayed grounded. Everyone focused on what needs to be true for an agent to work in production, inside a tool people use all day.

Internal tools make this possible. You control the workflow. You control the UI. You control how the system is instrumented. That gives you the foundation to build something reliable.

The takeaway for me is simple.

Agents do not fail because they lack capability. They fail because they lack context.

The next phase of agents will be defined by how well they understand the product they operate in. UI state, workflow position, user intent.

That is what makes the difference between something that works in a demo and something people trust in their day to day work.

Subscribe now

Share

SAP rival Odoo, is currently valued at $5.3 billion

Over the last decade SaaS became the dominant model for enterprise software. Every workflow became a subscription: CRM, HR, analytics, marketing, support. Entire companies built around selling access to a UI.

A combination of open-source software, AI agents, and better infrastructure is starting to challenge that model. Instead of buying software, companies are increasingly asking a different question:

Should we just build this ourselves?

One of our customers has done exactly this.

They replaced Salesforce with TwentyCRM. Their entire HR and ERP stack runs through Odoo. And their long-term plan is pretty simple: build most things internally using open-source software.

For years, building internal software was expensive, slow, and fragile. You needed a team of engineers just to recreate something Salesforce or HubSpot already did.

Now that assumption is breaking down.

And the data actually supports this shift. Today 83% of companies already use custom-built software somewhere in their operations, dashboards, internal workflows, automations, integrations , even though most still rely on off-the-shelf tools for standard functions.

At the same time, the global market for custom software development is roughly $43B today and projected to reach about $146B by 2030.

That kind of growth doesn’t happen unless companies are increasingly deciding to build more software themselves, and you can start to see this shift in the tools they’re choosing.

One of the clearest examples is open-source business software, especially platforms like Odoo.

Odoo has quietly become one of the fastest-growing ERP platforms in the world. What makes it interesting is not just that it’s open source , is that it behaves more like a software framework than a product.

You get accounting, CRM, invoicing, inventory, support, etc.

But the real point is that companies can modify it endlessly. Instead of paying tens or hundreds of thousands a year for multiple SaaS tools, teams can start with Odoo and customize the workflows they actually need.

The second signal is companies aggressively reducing their SaaS footprint.

A widely discussed example is Klarna. During its internal AI transformation the company removed over 1,200 external SaaS tools while automating large parts of internal workflows.

At the same time, Klarna deployed an AI assistant that handled 2.3 million customer conversations in its first month, doing the work of roughly 700 support agents while cutting resolution time from 11 minutes to 2 minutes.

The point here isn’t that AI replaces humans.

The interesting thing is that AI replaces software interfaces.

Instead of humans clicking through tools, agents interact directly with APIs and systems, orchestrating workflows across multiple products simultaneously.

When that happens, the UI layer, the thing SaaS companies sell, becomes less important.

But the easiest way I’ve found to think about this shift is actually food.

The food world has three basic models

• Restaurants

• Meal kits

• Grocery stores.

Each solves the same problem (feeding people) but in completely different ways.

And oddly enough, these map almost perfectly to how software is evolving.

1. Restaurants (Traditional SaaS)

Restaurants are the fully packaged experience.

You walk in, someone else cooks the meal, someone else designs the menu, someone else handles the logistics. Your only job is to consume the result.

Uber Eats and delivery apps pushed this even further. Now you can outsource cooking entirely.

This is basically what SaaS did for software. SaaS says: don’t worry about infrastructure, workflows, hosting, updates, engineering; we’ve already built the system. Just log in and use it.

Salesforce, HubSpot, Zendesk, these are restaurants.

And this made sense. Running your own software was like running your own restaurant kitchen, expensive and complicated. And in many cases, this is still the right choice. If something is truly best-in-class, it’s often cheaper to buy the experience rather than build it.

2. Meal delivery kits (Open-source platforms)

Then meal delivery services appeared: HelloFresh, Blue Apron, etc.

They changed the model.

Instead of cooking everything for you, they give you ingredients + recipes.

You still cook the meal, but the hard part, planning and sourcing, is done.

The model clearly resonated. The global meal-kit market is roughly $25–33B today and projected to exceed $70B over the next decade. In the U.S. alone it was about $10.4B in 2023 and is expected to more than double by 2030.

That’s what open-source platforms like Odoo or Twenty CRM represent.

They give you the structure of enterprise software, but let you modify it however you want.

You aren’t locked into someone else’s workflow.

3. Grocery shopping (build-it-yourself software)

Finally there’s grocery shopping.

You buy raw ingredients and cook everything yourself.

This used to be the equivalent of building internal tools from scratch, something only large tech companies could afford.

But AI agents are starting to change that too.

Agents can now write code, connect APIs, automate workflows, and operate software directly.

In other words:

AI is making building your own software dramatically easier.

The psychology behind these models is actually quite predictable.

Most people don’t cook every meal themselves, not because they can’t, but because of time, expertise, and convenience.

Restaurants win when people want simplicity.

Meal kits win when people want control but not complexity.

Cooking wins when people want full customization.

Software markets are starting to follow the same pattern.

For years SaaS dominated because it was the easiest option.

But as customization becomes easier (and cheaper) the balance starts shifting.

Companies are realizing something important:

They don’t actually want generic workflows.

They want software that reflects how their business actually works.

AI agents accelerate this shift even further.

Instead of humans navigating software, agents can execute workflows directly across systems, retrieving data, triggering actions, and coordinating tasks.

This changes the economics of software.

Traditional SaaS pricing is built on per-seat subscriptions.

But agents don’t buy seats.

They operate systems.

At the same time, even SaaS companies are moving toward agent-driven architectures. For example Salesforce now runs autonomous agents through its Agentforce platform, and its CEO has said AI already performs 30–50% of internal work inside the company.

That alone tells you something about where things are going.

So where does this leave SaaS?

Probably not dead.

Restaurants still exist. They’re just no longer the only way people eat.

What seems more likely is a shift in the software stack:

• Open-source platforms become the base layer

• AI agents orchestrate workflows on top

• SaaS products become components rather than destinations

Instead of logging into five different tools, companies will have systems that assemble themselves around their workflows.

The UI becomes optional.

The agent becomes the interface.

And software stops looking like products, and starts looking more like infrastructure.

One last thought.

The SaaS era optimized for distribution.

The next era might optimize for adaptability.

Software that can reshape itself around a company will always beat software that forces the company to reshape itself around the tool.

Which is why open source + AI + agents together feel like something bigger than just another technology shift.

It feels like the moment when building software becomes easier than buying it.

And historically, when that happens, markets change very quickly.

Subscribe now

Share

At first glance, it looks like that future is already here. New AI-native “replacements” for SaaS appear every week: AI CRMs, AI recruiting tools, AI design tools, AI everything. But once you actually use them, a pattern emerges: almost all of them lack robustness.

And robustness is the thing that matters most.

By robustness, I don’t mean polish or speed. I mean the ability to support real-world complexity: deep customization, edge cases, multiple stakeholders, evolving use cases, and scale over time. The kind of robustness you see in tools like CAD suites, professional photo-editing software, or enterprise CRMs. These tools work not because they automate everything, but because they let humans shape them endlessly around their specific needs.

Robustness is what allows software to scale horizontally and vertically. Instead of building a tool that solves one narrow problem extremely well, you build a system that can be adapted to many problems, and then further adapted within each of those problems. That’s why one piece of software can power thousands of companies, each using it in slightly (or wildly) different ways.

VCs understand this instinctively. That’s why, over the past decade, they’ve bet heavily on vertical SaaS; software that deeply understands a domain but still preserves flexibility. What we’re seeing now is the same bet being made again, just rebranded: vertical agents instead of vertical SaaS. The hope is that agents will finally be able to encode that flexibility automatically.

So far, they haven’t.

A big contributor to this problem is what people loosely call “vibe coding.” Yes, it’s impressive that you can spin up a prototype, or even a simple production app, in hours instead of months. But there’s a cost. Everything starts to look the same. The same layouts, the same interactions, the same mental models.

Vibe-coded software is limited by what the model thinks software should look and feel like. Which means that genuinely clever, opinionated, or novel UI/UX gets flattened into safe, repeatable patterns. That’s not just a taste issue; it’s a data issue. The model can only remix what it has seen.

As a result, most AI products end up differentiated by only two things:

1. The context data they’re plugged into

2. Minor UI variations on top of the same underlying interaction model
   

But here’s the problem: the moment you try to make that software more powerful, e.g. by adding features, supporting edge cases, or enabling deeper customization - you start removing AI from the critical path. You fall back to explicit controls, configuration, logic, and structure. In other words, software.

The most robust piece of software most people have ever used is probably Excel. At its core, it’s almost offensively simple. No opinions. No automation. Just cells and functions. Yet it works as both a backend and a frontend. You can model a business, run analytics, build workflows, or create something completely unintended by its creators.

Excel doesn’t succeed despite its lack of AI, it succeeds because of its raw, composable nature. AI can sit on top of it, but it’s not what gives Excel power.

This leads to an uncomfortable conclusion: a lot of AI today is being used to solve problems that don’t actually need to be solved.

Take AI in recruitment. In practice, most “AI recruiting agents” are just large language models wrapped around filters and keyword searches. Things that already exist and work very well with Linkedin recruitment or sales navigator. The pitch is that it feels magical the first time, type what you want, get results, but the magic doesn’t scale. It breaks down the moment you care about nuance, tradeoffs, or consistency.

They’re party tricks, not systems.

In these cases, AI doesn’t produce better outcomes. It just produces outcomes faster. And speed without robustness is rarely a long-term advantage.

This distinction matters a lot for how we think about AI at Autoplay.

Our AI features (golden path deviation, unsupervised clustering, hesitation detection etc.) are intentionally treated like functions. They’re closer to filters, tags, or functions/columns in a Google Sheet than they are to autonomous agents. Each one does something specific, deterministic, and composable. On their own, they’re not the product.

The product is the experience around them.

Autoplay should feel as robust as any serious analytics or product tool. That means our AI features must work in combination with non-AI features. They need to respect filters, cohorts, URLs, time ranges, and organizational context. They need to be debuggable, inspectable, and controllable.

Our first real mistake was leaning too hard into a semantic search / ChatGPT-style interface, asking questions like “Where do users get stuck?” That sounds powerful, but it’s fundamentally flawed. Without isolating control factors (specific cohorts, specific flows, specific dates), you don’t get truth. You get plausible answers.

And plausible answers are dangerous.

Real insight comes from constraint, not abstraction. Cohorts. URLs. Time windows. Comparisons. AI can help compute, surface, and suggest, but robustness comes from giving humans the tools to reason precisely.

The future isn’t AI replacing software. It’s AI becoming a primitive inside robust software. A function, not an agent. A building block, not the building.

And the companies that win won’t be the ones with the best demo, they’ll be the ones that understand that robustness is still the hard part.

Leave a comment

Subscribe now

Normally, when AI gets things wrong, it tends to hallucinate, confidently giving you answers that are completely off.

But this time, it wasn’t hallucinating. It was doing the opposite. It kept telling me what workflows “weren’t possible.”

Not wrong answers. Not made-up instructions. Just false negatives; the AI confidently claiming something couldn’t be done, even though it absolutely could.

This revealed a new problem: the co-pilot wasn’t actually reasoning about the product. It was reasoning about the documentation.

Co-pilots rely almost entirely on knowledge bases - documentation, forums, API pages, support articles - and those don’t always reflect how the products work.

This isn’t specific to PostHog.

It happens in every complex platform I’ve tried using a co-pilot with.

And the more I run into this, the more obvious the gap becomes:

co-pilots don’t understand the UI, the workflow, or the situation you’re actually in.

They understand text.

Here’s the breakdown of where things fall apart.

Co-pilots rely on documentation and forums, not the real product

Documentation tells you the “official” way to use a product.

Power users rely on workarounds, hacks, and discovering interesting combinations of features and workflows to achieve their own unique goals.

Docs rarely cover these.

So the co-pilot gives answers that are correct in theory, but too restricted to work in practice.

In my PostHog example, the co-pilot repeatedly said the workflow I wanted was “not yet possible” because the documentation didn’t describe that workflow.

I later explained the problem to a PostHog engineer, and he proposed a completely different approach.

Because he understood the actual goal (not the literal workflow I had described), he could see paths I didn’t know existed.

He wasn’t confined to the questions I asked. He wasn’t limited by my understanding of the feature set. He wasn’t restricted to what’s written down. He could reason across the product, not just answer inside it.

And when I asked the co-pilot how to follow the engineer’s instructions, it had no problem explaining the steps.

That’s the fundamental gap:

Co-pilots answer the prompt, humans answer the intent.

If it’s not written down, the co-pilot assumes it doesn’t exist.

Complex platforms can do far more than what’s written

Everyone who uses tools like PostHog, Datadog, HubSpot, Notion, Zapier, or Retool knows this:

There are a hundred things the product can do that are never officially documented.

You learn them by clicking around, testing settings, seeing how things behave under certain conditions, chaining features together, manipulating existing flows, and watching how the UI reacts.

This is the type of knowledge humans discover naturally, but co-pilots can’t access at all.

They don’t explore the UI. They don’t test. They don’t observe behaviour. They don’t learn from interaction.

Which means they fundamentally misunderstand how these products are actually used.

You can’t problem-solve with a UI you don’t understand

Documentation doesn’t always get updated. Old support articles don’t get replaced. Forum posts contradict each other.

The co-pilot is stuck in a snapshot of how the product used to work.

The deeper issue isn’t just that documentation gets stale, it’s that a co-pilot relying on static text can’t reason about what the product can do, only what the docs say it can do.

It has no ability to explore the UI, test different orders of steps, combine features, or try alternative paths to reach the same goal. So if the documentation only describes one “official” workflow, the co-pilot assumes that’s the only workflow that exists.

Humans do this instinctively. We try things. We click around. We chain features together. We change the order. We combine steps. We see what happens.

If you give someone a list of ingredients and one recipe, they’ll only ever make that one dish.

A real cook sees the same ingredients and immediately knows ten things they can make.

Full automation makes the problem worse

If the agent fully automates a workflow, and something is wrong (and something will be wrong) the user ends up needing to debug the AI’s mistake without understanding the underlying system.

This is especially painful when:

• the account has custom configurations

• the user has special permissions

• the data is messy

• the UI behaves differently for that workspace

• the workflow has branching logic

If something breaks, the user is blind.

This is the opposite of “help.”

Users don’t want to re-explain everything every time

Another practical issue:

If you repeat the workflow a week later, you don’t want to:

• rewrite the entire prompt

• specify every detail

• describe your setup again

• define the data sources

• re-explain the exact workflow

You want the co-pilot to:

• know your context

• remember your configuration

• understand your workspace

• and help you perform the next step

• not restart from scratch.

This is where UI understanding matters.

The context lives in the interface, not the prompt.

Co-pilots need to assist, not take over

Most people don’t want the AI to run off and complete everything.

They want:

• suggestions

• guardrails

• UI highlighting

• “this is where you went wrong”

• “this is the next step”

• partial automation

• shared control

Co-pilots should help with actions, not replace them entirely.

The real solution: let the co-pilot learn by interacting with the UI

The only way around all these problems is for co-pilots to understand software the way humans do - by using it.

Something closer to OpenAI’s Operator-style agents that:

• click through the interface

• test actions

• inspect elements

• understand actual UI states

• watch how the product behaves

• identify errors visually

• confirm steps through interaction

This would give the co-pilot access to real product knowledge, not second-hand descriptions.

The next generation of co-pilots won’t win on bigger models, they’ll win on better product understanding.

Until then, we’ll keep running into the same thing:

co-pilots that sound right but don’t actually help.

Share

Subscribe now

Every SaaS software company says they want their product to be more self-serve.

But inside most sales-led organisations, adoption still depends on people, account managers retaining users, success teams explaining workflows, and product managers wondering why users don’t find value without help.

The Hidden Comfort of Being Sales-Led

Why is there so much push back to becoming completely product-led?

Because great salespeople and CSMs can hide almost any flaw in the product. Customers never truly feel friction, they just message someone and the problem disappears.

Until it doesn’t scale.

At some point, you start hiring people not to grow the business, but to explain the product. You start mistaking hand-holding for success.

When that happens, humans end up doing what the product should be doing.

• CSMs teach customers where buttons are.

• Sales reps re-sell the same value every quarter because adoption never sticks.

• Product teams build from second-hand feedback and miss the real pain.

Everyone says, “We just need to improve onboarding.”

But onboarding isn’t the problem.

Dependence is.

A Product That Teaches Itself

A truly self-serve product teaches itself.

• It adapts when new users join a team.

• It re-boards when features change.

• It knows when someone’s stuck, and helps before they ask.

That’s the real test. Not whether users can “figure it out,” but whether the product can recover from confusion.

Customer success should be about helping users grow their accounts, not teaching them to click the right buttons.

If your CSMs are doing anything other than that, your product still has training wheels.

The Over-Correction Trap

A user gets stuck → you add a tooltip.

Someone complains → you add another setting.

A big customer asks for something → you build a feature.

Pretty soon you’ve solved for every edge case and made the core experience worse for everyone else.

Every product has a group of users who will always be confused. The trick is knowing when that’s a product problem and when it’s a growth problem.

If 80% of users are fine and 20% aren’t - that’s not bad UX, that’s an opportunity for education or automation.

If 80% are struggling, that’s a product issue.

Most companies never make that distinction. They just throw more people at the problem.

Why Product Signals Aren’t Enough

Funnels and events tell you what happened, not why.

A drop-off isn’t an insight, it’s a symptom.

What matters is intent – what the user was trying to do.

Because only then can you decide who owns the problem:

• Product, if the path itself is broken.

• Growth, if users don’t know the path exists.

• CS, if they know it but can’t connect it to outcomes.

Without that context, teams optimise blind, fixing symptoms and wondering why nothing compounds.

From Sales-Led to Self-Serve: Where to Start

1. Self-Serve Starts Inside Your Sales-Led Motion

Sales-led growth doesn’t disappear when you go self-serve, it evolves.

The best teams aren’t removing humans; they’re automating the moments around them:

• Onboarding emails triggered by real behaviour, not fixed sequences.

• Guidance personalised by intent, not generic feature tours.

• Friction detection before it turns into a support ticket.

2. The Hidden Cost of Re-Onboarding

Most companies nail the first 30 days. Calls, walkthroughs, check-ins.

But after that, things decay.

Teams change. The product evolves. New users join existing accounts.

The “how-to” knowledge lives in outdated Looms, slack threads and internal SOPs.

It’s not an onboarding problem, it’s a re-boarding problem.

CSMs become the product’s memory, constantly retraining users on what’s changed.

Self-serve companies solve this by detecting when someone new joins, recognising first-time patterns, and automatically guiding them to value.

Consistency shouldn’t depend on who’s still in the Slack channel.

3. User Goals Change, Your Context Should Too

Customer intent evolves.

The reason someone bought six months ago isn’t always why they use it today.

Without visibility into that shift, teams end up:

• Creating their own SOPs to make the product “fit.”

• Misaligning Sales, CS, and Product around outdated goals.

• Chasing the wrong problems because they’re anchored to old intent.

You can’t fix that with static CRM notes or funnel data.

You need to interpret what users are trying to do in real time, and adjust what you show or automate accordingly.

The best teams personalise not by role or plan, but by intent.

4. Product Signals + Sales Signals = Expansion

Sales-led teams are wired to watch the big picture, buying signals like company growth, new hires, expansion plans, or renewed budgets.

When you optimise around revenue metrics alone (logins, seat counts, contract size) you miss the product-side intent: understanding what users are trying to do before those signals ever show up.

A user might look “healthy” on paper but still be stuck in the workflow.

Self-serve maturity comes from connecting those two worlds, pairing the external business context with what’s really happening in-product, where intent-to-buy meets intent-to-use.

5. The Edge-Case Problem

Every product has edge cases, users who get 90% there, but not quite.

Product teams build for the majority.

CS and Growth teams live in the margins.

The key is scale:

• If 2% of users are stuck, it’s a growth problem.

• If 20% are, it’s a product gap.

You can’t know which without intent-level data, connecting behaviour, friction, and context in one place.

Before changing the product, isolate the cause:

1. Was onboarding insufficient?

2. Were expectations mis-set in Sales?

3. Is it the wrong ICP?

6. What Self-Serve Really Means

Self-serve isn’t about removing humans.

It’s about giving them context before they’re needed.

The best companies automate understanding, not empathy.

They:

• Detect intent, friction, and change.

• Surface insights to CS and growth.

• Automate guidance when it’s routine, and flag it when it’s strategic.

When that happens, humans finally get to do what they’re best at, helping customers grow, not teaching them to click.

Share

Subscribe now

It was called Clippit, or more famously, Clippy. The idea was decades ahead of the technology that powered it.

The arc matters because modern products are quietly re-introducing assistants, but with better timing, better intent, and better outcomes.

Why it started (history)

In 1996–1997, as Microsoft prepared to ship Office 97, it faced a problem: users were overwhelmed by menus, ribbons, and hidden features. The company wanted a “human” interface between people and software: a companion that could sense what the user was doing and offer help in real time.

Clippy was the result. Designed by Kevan J. Atteberry, Clippy was part of the Office Assistant, powered by early Bayesian inference models - primitive probability systems that guessed user intent based on small cues.

If a user typed “Dear …” → it likely meant “writing a letter.”

If a user opened the Tools menu repeatedly → they were probably “looking for a setting.”

Underneath, this was all logic trees and conditional probabilities - not natural language understanding. There were no embeddings, no transformers, no context memory. The assistant was running a static rule base embedded in Office, built on Microsoft’s Agent platform, a descendant of the Microsoft Bob project from 1995.

Clippy was a kind of hardcoded agent – an interface shell around structured rules, not reasoning. It looked alive, but it couldn’t really think.

Why it failed

The failure wasn’t because the idea was bad - it was because the technology couldn’t deliver what the interface promised.

• No real intent modeling. Bayesian triggers worked on single-word cues, not multi-step context. If you typed “Dear…” in a poem, Clippy thought it was a letter.
  

• No personalization. Clippy had no user memory - every interaction was the same. It couldn’t learn from you or adapt.
  

• Intrusive by design. It appeared automatically, often mid-task, because it lacked the subtlety to know when help was wanted.
  

• No feedback loop. It couldn’t improve or be fine-tuned; the model lived inside your Office install.
  

By 2001, Microsoft disabled it by default in Office XP, and by 2007, it was gone entirely.

The idea of software that knows when you need help went dormant for almost two decades.

The rebirth – and why it matters now

When LLMs emerged, they reintroduced something Clippy always wanted to be: context-aware.

Assistants like GitHub Copilot, Microsoft Copilot, and ChatGPT are powered by transformer-based language models – systems that don’t rely on keyword triggers, but on probabilistic reasoning across massive context windows. They can infer what you mean, not just what you type.

In 2025, Microsoft introduced Mico, a new Copilot avatar with expressive, real-time reactions and voice-mode presence - a modern, optional embodiment of help. A hidden Clippy Easter egg nods to the past without repeating it.

Press framing is explicit: Mico aims to succeed where Clippy failed - more empathetic, less intrusive, and tuned to today’s expectations for useful, collaborative AI.

How the assistant returns to software (done right)

Today’s copilots are powerful, but still reactive. They respond to language, not behavior.

If a user hesitates or gets stuck without knowing why, the copilot stays silent until prompted.

The next step is moving from assistants that listen to ones that notice.

Modern assistants should work in the flow and for the outcome. Instead of generic “Need help?” balloons, they watch for signals: hesitation, repeat errors, dead-ends, oscillation, or divergence from a known golden path.

When confidence is high - and only then - they surface a targeted nudge, a micro-guide, or an action.

Where this is heading, and what we’re exploring at Autoplay

At Autoplay, we’ve been developing Pinnie the Pin Pal.

• What it is. A proactive chat presence that infers intent not from text, but from behavior and context. It pops up only when users may be stuck or deviating from the expected flow.
  

• Where it appears. Anywhere friction concentrates: beside a disabled button, near a mis-configured form, inside a multi-step wizard, or inline on a page where users routinely stall.
  

• What it does. Offers the next best step, clarifies prerequisites, highlights the one control users keep missing, or links to a short, relevant walkthrough.
  

Pinnie is powered by TERRA, Autoplay’s framework for predicting user intent by combining UI understanding with user clicks to form a unified ontology for measuring and evaluating user goals.

It’s the same vision Microsoft had in 1997 - helping users reach value faster - but finally with the technology to do it right.

Why this is different from Clippy (and better)

• Inference over interruption. Pinnie uses behavioral signals (deviations, repeated back-and-forth, long hovers, rage-clicks) to predict intent and time help; Clippy relied on shallow triggers (keywords and canned heuristics).
  

• Context and control. Pinnie is subtle and optional, appears in place, and respects dismissals and user preferences. Clippy was on by default and hard to tune.
  

• Outcome-driven. Pinnie’s goal is path completion and adoption (finish a setup, export data correctly, publish the first automation), measured by golden-path completion and drop-off changes, not just “help opened.”
  

• Segment-smart. Behavior adapts by persona and journey stage (new vs. power user; admin vs. contributor), avoiding one-size-fits-all prompts.

Design lessons (Clippy → Pinnie)

1. Appear only with confidence. Low-precision prompts erode trust fast.

2. Help in place. Avoid modal hijacks; anchor near the friction.

3. Make it dismissible, and remember. Respect “not now,” and learn from it.

4. Short, specific, actionable. Offer the step that moves the user forward.

5. Measure behavior change. Track impact on completion, retries, abandonment, not vanity clicks.

Closing note

Clippy was an early, lovable misfire - a product of its moment and its limits. 1997–2007 taught the industry that help without context becomes an interruption. 2025 brings a different pattern: assistants that listen first, then assist. That’s the lane Autoplay (Pinnie) occupies - a context-aware, intent-informed guide that appears only when the product itself signals friction. The face isn’t the point; the moment is.

Leave a comment

Subscribe now

What happens when software stops waiting for us?

The history of software has always been about efficiency. Better UI, clearer workflows, faster time-to-value. Today, most tools feel good enough. The interfaces have converged into a shared design language; dropdowns, sidebars, dashboards. The cognitive tax of using new software is lower than ever.

But the irony is that as software became easier to use, it also became easier to build. Every product now looks and feels the same. AI code copilots have made shipping new features fast, but the end result is more homogeneity, not less. Everyone has the same design patterns - the same onboarding tours, the same chatbot in the corner of the screen, the same PLG playbook to “drive adoption.”

The next leap won’t come from prettier UIs or more polished onboarding. It will come from software that knows what you’re trying to do, and helps you do it before you ask.

That’s where proactive agents come in.

The Problem with Today’s Co-Pilots

Most “AI copilots” today are reactive. They’re powerful, but fundamentally dumb in context. They wait for you to tell them what to do, and then they execute it. They don’t observe, reason, or infer.

Even when they connect to APIs or automate workflows, they rely on prompting, which assumes the user knows what they want, how to phrase it, and how the system works underneath. That’s a big assumption.

Prompting feels magical the first few times, but it’s still the human doing the cognitive heavy lifting. You need to know how to frame the problem, which tool can solve it, and what parameters matter. It’s like having a brilliant assistant who can do anything, but only if you give them perfect instructions.

And that’s the paradox: prompting rewards expertise. It benefits people who already understand the system. For everyone else, it’s a new kind of friction, a UX regression disguised as progress.

We’ve seen this before. The earliest software required deep expertise to operate: command lines, nested menus, rigid workflows. Then came the UI revolution, which abstracted complexity away. Prompting reverses that, and puts the work back on the human.

So if the co-pilot still needs the pilot to fly, have we really changed anything?

Why the Future Is Proactive

The next generation of co-pilots will be proactive, not reactive.

They’ll observe what you’re trying to do, anticipate where you’re going, and suggest or act accordingly, like a colleague who’s already one step ahead.

Instead of waiting for a prompt, they’ll watch your behavior, detect hesitation, and know when to step in. They’ll understand the difference between someone exploring a feature and someone clearly stuck. They’ll see that you’re creating a campaign, not just editing a field, and they’ll know the typical next three steps because they’ve seen thousands of users like you.

That’s the future of software adoption, productivity, and support.

But it requires solving several hard problems that the industry mostly ignores right now.

1. Context Is Still Fragmented

Every tool defines the world in its own terms: “projects,” “deals,” “campaigns,” “workflows.” None of them talk to each other meaningfully.

So when an AI connects across them, it’s moving data, not understanding it. It can describe events, but not interpret goals.

We built TERRA at Autoplay to solve exactly this. It’s a unified ontology - a common language that describes how software behaves, what users are trying to do, and what efficient workflows (“golden paths”) look like.

It lets our models reason across apps and industries. To know that creating a “new project” in Asana, a “campaign” in HubSpot, or a “workflow” in ActiveCampaign are the same conceptual action - initiation toward an outcome.

Without that kind of layer, AI will stay narrow and reactive; task executors rather than intelligent collaborators.

2. Trust Is the Bottleneck

You can’t automate what people don’t trust.

If an AI acts without explaining why, users will override it or turn it off. For proactive systems, transparency becomes non-negotiable.

That means clear reasoning: “I noticed most users drop off at this step, so I simplified it,” or “I pre-filled this field because it matches your past patterns.”

The UX of automation is no longer just usability, it’s legibility.

People don’t need perfection; they need confidence that what’s happening makes sense.

Trust isn’t built through accuracy alone. It’s built through explanation.

3. Autonomy Needs a Dial

Autonomy is a spectrum, not a switch.

Too little, and the agent is annoying constantly asking for permission.

Too much, and it’s dangerous, making changes you didn’t consent to.

Proactive systems will need adaptive autonomy. They’ll start in observe-and-suggest mode, then gradually earn the right to act as they prove reliability.

Just like a human teammate, trust expands through consistent, predictable behavior.

4. Real-Time Grounding

Large language models are great with text but blind to state. They don’t actually see what’s on screen, which buttons exist, what data is visible, or whether an action succeeded.

Without real-time grounding, AI actions are educated guesses.

Proactive agents need to perceive the same reality the user does – live product state, current workflow, system feedback. That’s why grounding in UI understanding (not just API data) is so critical.

Without it, AI remains a clever autocomplete for your clicks.

5. Privacy and Access

To anticipate intent, agents must observe behavior. But observation at scale raises obvious privacy concerns.

Companies want automation, but they can’t afford invisible data flows. Users want help, but they don’t want surveillance.

The solution isn’t less context, it’s smarter context.

Local inference. Edge processing. Synthetic abstractions. Systems that learn patterns without storing personal data.

If proactive AI is going to work, it has to earn access, through governance, transparency, and clear data boundaries.

Where It All Leads

For years, “good UX” meant minimizing clicks. The next era will be about minimizing cognition.

The most powerful software will feel like intuition, where help arrives exactly when you need it, without you asking.

That doesn’t mean removing control; it means removing unnecessary translation. Users shouldn’t have to think in software logic. The software should think in theirs.

That’s the vision behind Autoplay.

We’re building systems that can see intent, hesitation, and deviation, and connect them through a unified understanding of how software works.

Because the real bottleneck in AI isn’t model quality; it’s context.

And the real opportunity isn’t faster execution; it’s faster understanding.

We believe the future of copilots is proactive - systems that act before you ask, learn before you teach, and adapt before you notice.

When that happens, software won’t just feel easier.

It’ll feel like it finally understands you.

Subscribe now

What’s faster: clicking around in an interface, or prompting an AI to act on your behalf?

At first glance, it feels obvious: AI should win. Why waste time dragging blocks or formatting text when you could just ask for it?

But when you zoom out, speed isn’t just about how fast the software responds. It’s about how quickly you can iterate toward the result you actually want.

And in that sense, the future isn’t a battle between prompting and UI - it’s a partnership.

Two Kinds of Thinking

Most of what we do inside software falls into one of two modes.

Type 1: Execution.

These are mechanical, operational tasks, formatting a slide, adding rows to a spreadsheet, moving blocks in Notion. They’re structured, predictable, and visual. You don’t need creativity; you need control. And here, the mouse wins. Clicking through a UI is faster, less effortful, and cognitively lighter.

Type 2: Organization and Strategy.

This is the messy stuff, turning a brain-dump into a meeting summary, clustering ideas after a brainstorming session, or shaping raw notes into an outline. It’s abstract and unstructured. Here, prompting shines. You can ask an AI to “make sense of this chaos,” and it will - faster than you ever could manually.

This idea isn’t new, it echoes psychology’s classic distinction between System 1 and System 2 thinking, introduced by Daniel Kahneman. System 1 is fast, intuitive, and automatic, like clicking through familiar actions without much thought. System 2 is slow, deliberate, and analytical; the mode we enter when we need to organize, plan, or reason through messy problems.

Software today forces you to toggle manually between these modes, and the next generation will adapt to whichever kind of thinking you’re doing in real time.

Clicking is best for precision; prompting is best for sense-making.

The Hybrid Workflow

The real magic happens when you stop thinking of prompting versus UI, and start moving fluidly between them.

You might ask AI to clean up your notes (a Type 2 task), then jump back into the interface to reorder or refine details (Type 1).

Each mode plays to the other’s strengths.

This back-and-forth, prompt, click, prompt again, becomes the new loop of productivity.

When Prompts Become Buttons

Over time, patterns emerge. You might find yourself typing the same prompt every morning:

“Show me my calendar events today.”

At some point, the system should notice.

Typing the same thing every day is slower than clicking once. So the prompt evolves into a button - “Show Calendar” - waiting for you next time you open the app.

That’s the principle: repetition should generate UI.

Prompts are where discovery begins; buttons are where efficiency stays.

When Conversation Becomes Interface

Strategic, novel tasks will always begin as conversation. Routine, predictable tasks will always crystallize into UI.

The future interface blends both, a living surface that learns from how you think.

Conversation spawns new UI elements.

UI, in turn, accelerates your next conversation.

It’s not about talking to software anymore; it’s about software that talks with you.

The Human–Computer Loop

What this hybrid model really optimizes is the mental loop itself:

Thought → Interaction → Thought.

You externalize your messy ideas through a prompt.

You refine them through the UI.

You see the outcome, learn from it, and your next thought gets sharper.

It’s a cycle of cognitive offloading, software adapting to human thought, not the other way around.

The Big Picture

We’re heading toward software that can think ahead of us.

Conversational AI will be embedded directly inside interfaces.

You’ll move between prompting and clicking depending on what’s faster in the moment.

Over time, your software will:

• Learn which actions you repeat

• Turn them into shortcuts

• Let you spend prompts on the high-level, creative stuff

The interface will evolve with you, each prompt giving birth to a new button, each button freeing up mental space for bigger ideas.

Where Autoplay Comes In

At Autoplay, we think the next leap is before the prompt.

We’re building a pre-intent layer - a system that predicts what you’re trying to do before you have to ask.

It reads behavioral context (clicks, hesitations, navigation paths) and infers intent in real time:

“Designing a presentation.” “Analyzing churn.” “Inviting a teammate.”

From there, it can surface contextual prompts, or take the action automatically.

If you hover over a chart, it might whisper: “Explain this?”

If you reformat slides for the third time, it might offer: “Want me to make them consistent?”

The assistant learns your rhythm, adapts its behavior, and eventually begins prompting the software on your behalf.

Measuring the Shift

This isn’t just UX polish. It’s cognitive optimization.

By predicting intent, we remove friction at three levels:

1. Intent formulation: you don’t have to decide what to ask.

2. Prompt translation: you don’t have to phrase it perfectly.

3. Iteration: you don’t have to re-prompt endlessly - the system adjusts automatically.

The result: faster task completion, fewer prompts, and lower mental load.

The Endgame

The future of software isn’t about choosing between conversation and control.

It’s about merging them; turning clicks into language, and language into action.

When AI can infer what you mean before you say it, prompting becomes invisible.

Software finally starts to feel like thought.

That’s where we’re headed:

A world where the UI adapts to how you think, and your thoughts flow directly into what the software does.

Subscribe now

What Odoo Actually Gets Right

If you’re new to it: Odoo is a modular system that covers the unglamorous but essential parts of a company - HR, Inventory, Accounting, Sales, Helpdesk, e-Sign, you name it - in one ecosystem. No brittle bridges between five vendors. One data model. One permission model. One place to automate.

Small teams can start with a couple of modules (like we did). Larger orgs can go deep with custom workflows, multi-company, and audits without the typical “ERP for a year” timeline.

The pitch sounds simple. The compounding effect is not.

How it looks:

With Odoo

Without Odoo

The honest bit: what wasn’t smooth

Switching tools doesn’t erase habits. We still hit real friction:

• Time-off: “Which policy applies? Who approves? Where do I see it?” Not always obvious.

• Sign: Templates vs. uploads created detours; a few folks still downloaded PDFs out of habit.

• Access: Hard to keep track of who had what across multiple tools - permission audits turned into Slack archaeology.

• Cost creep: Each app carried its own monthly fee and extra seats “just in case.” None painful alone, but together they added up - especially when usage was uneven.

None of it was catastrophic. But friction (and subscription sprawl) kills adoption if you let it linger.

Adoption Ground Rules (Day 0)

The main suggestion: make the default path obvious.

In Odoo, half the adoption battle is reducing choices. Hide menus users don’t need (per role), set default list filters and saved views so people land where work actually happens, and make the role home (Favorites) point to just two things: “Request time off” and “Sign/Review.”

Pre-build a few Sign templates with fields anchored so no one ever drags boxes again. Use Activities to auto-create the next step (e.g., submit → manager gets “Approve Leave” task), and a simple Automation/Server Action to assign the right reviewer and auto-archive signed docs.

Fewer routes = fewer detours; the right behavior becomes the effortless one.

How we used Autoplay on our own Odoo project

Odoo’s power lies in its flexibility, and that also makes it… a lot. Even with a PLG mindset, you’re still dealing with new terms, deep menus, and “ten ways to do the same thing.”

We didn’t want our rollout to trade one kind of drag for another, so we ran Autoplay on our own Odoo from day one. The goal wasn’t to watch more replays - it was to keep a tight, repeatable loop that spots where confidence drops and fixes those exact moments before they spread.

Here’s what that looked like in practice:

1) Define the Golden Path (per flow, per role)

Set the “first-lap” version of success so we knew what we were measuring against.

• Time-off (Employee → Manager): Request → Manager review → Approval → Calendar update

• Sign (Ops → Signer): Choose template → Fill fields → Send → Sign → Archive

No heroics. Just the shortest path that builds trust and reduces “how do I…?” DMs.

2) Watch the signals (daily, ~15 minutes)

Autoplay turned usage into a quick morning read:

• Hesitation: pause → hover-backtrack on steps like Validate / Sign

• Workarounds: exporting or detouring outside the flow

• Deviations: skipping steps / bouncing between pages

• Cohorts: where new joiners vs managers struggled

Odoo’s breadth means the same action can be reached three different ways. The point wasn’t to police exploration - it was to catch the moments where uncertainty consistently spiked.

3) Fix the moment, not the module

We resisted the “big training” instinct and targeted the exact sticking points:

• Microcopy where people paused. (“What happens when I click Sign?” → “Sends for signature. You can cancel anytime before send.”)

• Standardized Sign templates. No guessing which fields belong where.

• Access clarity. Tightened permissions, added SSO, wrote down “who approves what.”

• Three 90-second clips for first-time use. Not a course - just the first lap.

This wasn’t always one-and-done. Some tweaks didn’t move the needle. We rolled them back and tried the next smallest change. Odoo is flexible; your fixes should be too.

4) Re-check tomorrow

Same flows, same signals:

• Did hesitation drop at that step?

• Did completion rise?

• Did detours shrink?

If yes, keep going. If not, try the next nudge. Over a few weeks, the result was fewer DMs, fewer detours, faster cycles - not because we ran a bootcamp, but because we removed the specific moments that made people unsure.

Why did we do it this way?
Odoo can absolutely be “set it and forget it” for simple teams, but its real value shows up when you lean into its depth. That depth also raises the adoption bar. Running Autoplay on our own rollout gave us a guardrail: if a change slowed people down, we saw it the next morning - not three weeks and ten meetings later.

Odoo’s flexibility is a feature, not a tax - if you pair it with a tight feedback loop. Define the path, watch the signals, fix the moment, check tomorrow. Repeat until confidence is the default.

Sell the Calm, Not the Tool

Don’t sell “Odoo” internally. Sell one calmer week: HR that isn’t a scavenger hunt; Sign that doesn’t stall; time-off that doesn’t need a thread.

Start with one flow. Define the path. Remove the scary step. Check tomorrow. Repeat.

Odoo gave us the rails. Autoplay helped us keep the train on them. The result wasn’t a big go-live moment. It was a steady reduction in friction until the boring work stopped being loud - and the meaningful work got more of our attention.

Subscribe now

A chatbot that could take a command - “Schedule this report for me” - and then go do it, directly in the UI.

But we ran into a hard truth: copilots don’t fail because the AI can’t click the right buttons. They fail because people don’t know what to ask.

Users don’t know what they don’t know. They don’t know which features exist, what’s possible, or how others in their org are using the product. And even if they did, they only want answers that are relevant to them in that moment. That was the core hypothesis Autoplay was built on:

1. Users don’t know what they don’t know

2. Users only want to be shown or told what is relevant to them and what they don’t already understand

3. Users want to understand how others in their organization/team use the same software

4. Users will enjoy using the product more if it’s presented through a gamified experience

That’s why we shifted from “do-it-for-me” copilots → into “show-me-why” intent detection.

Step One: Recording the Right Data

At first, we tried the brute force route: screenshots and computer vision.

It was slow, expensive, and it missed crucial context like hover time, mouse drift, hesitation.

Then Monday.com gave us a better idea:

“Why not plug into our session replays instead? See if AI can do more there.”

That unlocked everything.

Atlas: Why Session Replays Became Our Wedge

We realized something obvious in hindsight:

Product teams hate watching session replays, but they have to, because that’s where the “why” lives.

So we built Autoplay Atlas.

It takes raw replays and turns them into high-impact insights:

• Where users hesitate

• What they know vs. don’t know

• What goals they’re trying to achieve

Instead of hours of replay watching, you get immediate clarity.

Building the Models

We started by converting video into frames and training models on hesitation, knowledge, intent.

Early versions meant uploading FullStory or Sentry links and getting back a summary.

From there, we layered on conversational intelligence into individual sessions: a chatbot you could ask,

“What can you tell me about what they user is trying to do”

By November, our models could reliably detect intent. Genie (our UI assistant) was starting to adapt in real time. We began asking customers whether they wanted us to integrate with existing replay tools (PostHog, FullStory, Hotjar) or replace them outright.

Scaling the Pipeline

February

• Shipped smarter NLP - questions like “Show me hesitation during onboarding filters” just worked.

• Knowledge and hesitation models got sharper.

• Added search across sessions + hypothesis testing.
  

April

• Redesigned the timeline for clarity.

• Launched collection summaries.

• Search was upgraded with unsupervised clustering - surfacing emergent goals and golden path deviations.

• PostHog came on board to help us scale infrastructure and co-sell.
  

May

• Golden Path shipped: define your ideal workflow, then instantly see where users deviate.

• We refined our ICP: PLG martech tools with clear adoption paths (campaigns, integrations, automations). Complex enough for AI to matter, narrow enough to measure impact.

• Outbound focused here → first commit in from Sendlane.
  
  

Thinking in First Principles: TERRA

As we mapped intent at scale, we developed TERRA:

Task, Event, Representation, Reasoning Architecture.

It’s the most efficient way we’ve found to connect raw clicks → to meaningful goals.

And it powers everything from hypothesis testing to real-time copilots.

Hypothesis Testing: One Flow, Not Ten Tools

The current adoption problem:

• Time-to-value is too slow.
  Teams stitch together multiple tools to ask simple questions: Is this drop-off caused by a bug, a bad UX pattern, or a user decision?

Our answer: turn everything into tags.

• An Issue = tag:issue_onboarding.

• A Golden Path = tag:golden_path_activation.

• A Hypothesis = tag:hypothesis_filters_confusion.

Instead of bouncing between views, you stay in one unified search canvas. Every step is traceable, shareable, repeatable. The agent can run the flow end-to-end: check for bugs, compare hesitation before/after, classify outcomes as decision vs. UX.

It’s hypothesis testing, but agentic.

Where We’re Headed

We’re pushing into agent-driven workflows, where Autoplay doesn’t just surface friction but tests it automatically.

Future R&D:

• Labeling data via chatbot interactions → supervised learning + RLHF.

• Session replay–powered copilots that intervene in real time.

• Tight integrations with PostHog error tracking, cohorts, and feature flags.

The long-term vision loops back to where we started: real-time copilots. But this time, grounded in user intent, context, and data.

Subscribe now

“Step 3 drop-off is 47%.”

Okay - but what were users actually trying to do? Did they intend to finish that flow, or were they just browsing? Did they get blocked by a bug, by the UX, or because it wasn’t the right task for them in the first place?

When the unit of analysis is a click, everything looks like a funnel problem.

When the unit of analysis is a goal, prioritization gets simple.

This write-up lays out a quiet shift that changes how growth work gets done: define real user goals, verify completion, then decide - sharpen the path or ship something new.

Start from intent (not events)

Before instrumenting anything, pin down who and why:

• ICP / Industry / Plan: early-stage SaaS, SMB vs mid-market, free vs trial vs paid.

• Role: admin, operator, manager, exec.

• Use case: “Send first campaign,” “Invite the team,” “Export a board,” “Create an automation.”

Then translate that into a plain-language goal:

“Create and schedule the first campaign.”

“Invite two teammates and assign roles.”

“Connect a data source and sync once.”

If intent isn’t explicit, completion rates won’t mean much.

Define “done” like a contract

A goal without proof is just a wish. Give each goal a Done Definition:

• Start signal: the first clear action that commits to the goal (e.g., “Clicked New Campaign”).

• Completion signal: the irreducible proof (e.g., “Campaign scheduled” event with a valid audience).

• Quality bar: lightweight guardrails (e.g., audience ≥ 1, no validation errors).

• Timeout window: how long counts as the same attempt.

Now the metric isn’t “page views.” It’s Goal Completion.

The five numbers that matter

For each goal, track:

1. Seen – users who encountered the goal entry point

2. Started – users who committed to it

3. Completed – users who hit the proof of done

4. Time to Goal – median time from start → done

5. Hesitation Rate – % of attempts with pause / loop / backtrack patterns

(Optionally add Assist Rate: cases needing help - chat, tooltip, doc - before completion.)

These five beat a dozen charts because they tell the whole arc:

intent → execution → confidence.

A simple decision tree for roadmap calls

Once the numbers are on the board, decisions get boring - in a good way.

A. High intent, low completion

• Likely cause: bug or UX/process friction.

• What to check: hesitation spikes on specific steps, repeat errors, back-and-forth loops.

• Action: fix the moment (microcopy, defaults, step order), not the whole module. Re-measure in 48 hours.

B. Low intent, high completion when started

• Likely cause: positioning / discovery problem.

• What to check: who sees the entry point, source campaign, feature findability.

• Action: move, rename, or pre-qualify the entry; teach benefits earlier; target the right cohort.

C. One power user, everyone else idle

• Likely cause: org-level adoption gap.

• What to check: invites, role assignments, teammate comparisons.

• Action: targeted enablement for named users on named steps. Don’t run a 50-person training.

D. High completion, slow Time to Goal

• Likely cause: cognitive load.

• What to check: steps with long dwell, unnecessary fields, decision bottlenecks.

• Action: remove fields, prefill defaults, progressive disclose. Shave minutes, not pixels.

Weekly “goals review”

Thirty minutes is enough if the inputs are clean.

Prep (15 min)

• Pick 1–3 goals that drive money (activation, upgrade, expansion).

• Sort by: high Seen, low Completed, or spiking Hesitation.

• Draft a cause hypothesis: bug / UX / knowledge / discovery.

Meeting (15 min)

• For each goal: show intent, completion, time, hesitation.

• Agree the smallest change that could move the number in 48 hours.

• Assign owner, deadline, and the single metric that will confirm it worked.

Everything else goes on a parking lot. The point is momentum.

Instrumentation that won’t eat your week

You don’t need a NASA stack to start. A minimal, durable setup:

• Events: goal_started, goal_completed, assist_shown, error_name, step_name.

• Context: role, plan, source campaign, account size.

• Tags / segments: ICP, industry, use case.

• Replay (optional): only to sample the stuck steps, not for doom-scrolling.

Save the query as “Goal: {name} - Weekly.” Rinse, repeat.

What to look for in behavior (the tells)

• Hesitation clusters: pause → hover → backtrack on the same control (“Validate,” “Confirm,” “Post”).

• Deviations from the golden path: unnecessary detours, step skipping, tab ping-pong.

• Workarounds: export → spreadsheet → re-import to “make it work.”

• Form thrash: repeated field edits, validation loops, error-copy rereads.

• Outlier time: steps where one cohort is 2–3× slower than peers.

• Org imbalance: one “hero” user vs. idle teammates.

These tells separate “needs a tooltip” from “needs a redesign” from “needs a fix.”

Two quick examples

Upgrade intent, stalled: lots of pricing views + team invites, few plan changes.

• Read: high why, broken how.

• Likely fix: make upgrade the natural next step in-flow; clarify limits; offer safe preview of paid features.

First automation, never activated: many starts, long time, low completion.

• Read: motivation exists, confidence doesn’t.

• Likely fix: template first; prefilled sample; show a dry-run result; rename scary steps; add “undo.”

In both cases, the question isn’t “what page is worst?” It’s “what goal is failing, for whom, and why?”

Where Autoplay fits (and what we learned building it)

We built Autoplay around this exact loop. Instead of highlighting clicks, it detects intent, hesitation, and deviation with UI awareness, then maps them to goals: who tried, who finished, and what got in the way. The value isn’t another dashboard; it’s faster answers to the only question that matters for growth:

Do users achieve what they came to do - and if not, is the win fixing the path or adding capability?

Use whatever stack you have to run the loop. Autoplay just compresses the time between “we think” and “we know.”

The quiet north star

Teams love big north-star metrics. Here’s a smaller one that moves them all: Time to Confidence - the time it takes from intent to “I can do this unaided.”

Shorten that, and activation rises, upgrades stick, expansions feel obvious.

Miss it, and the roadmap fills with features that look good in a deck and gather dust in the product.

Name the goal. Define “done.” Watch the tells. Fix the moment.

When the unit is a goal, growth becomes a series of easy decisions.

Subscribe now

A study by Carnegie Mellon University and Salesforce found that state-of-the-art AI agents succeed only about 30–35% of the time on multi-step office tasks.

For simpler, single-turn tasks, the success rate is higher (around 58%) but it drops sharply as tasks get more complex. The Register.

One use case that’s been surprisingly successful, but often overlooked, is AI for automated tagging and categorization.

Take Mem AI, for example:

Mem.ai has a feature called AI-Powered Tagging, which analyzes the content of your notes and assigns relevant tags automatically.

They also offer Collections, which neatly group notes by content and context, so you don’t waste time dragging things into folders.

And it’s not just Mem. Even workflow tools like Zapier are teaming up with Evernote to bring AI into tagging, making note organization smoother than ever.

Superhuman took AI tagging to emails:

One of the biggest challenges with emails? There are just too many emails.

Superhuman solved for this with their auto-labels. Their system instantly tags emails as “Pitch,” “Marketing,” and more.

It’s been a game-changer. Instead of getting lost in the noise, I can zero in on what’s actually important. If I want to catch up on pitches or dive into marketing emails, I do it on my schedule - not when they land in my inbox.

With Superhuman, staying organized feels effortless, and you finally get to spend your attention where it counts.

AI tagging plans for Autoplay

One of the biggest challenges with session replays? There’s just too much data.

Teams often get stuck - unsure which sessions matter, what questions to ask, or how to find the insights they actually need.

So we are following Superhuman’s footsteps:

Instead of building yet another “AI that does it all for you,” Autoplay turns everything into a tag. Those tags become the foundation for exploring user behavior, forming better hypotheses, and measuring real impact.

Just like Superhuman reinvented email with smart auto-labels, we’re reimagining how teams make sense of user behavior.

Everything becomes a tag - and tags become your filters

In Autoplay, Intents, Issues, Golden Paths, Hypotheses, Causes, and Segments aren’t special entities. They’re just tags on sessions.

• Clicking into an Issue? It applies tag:issue_onboarding

• Exploring a Golden Path? You’re seeing sessions with tag:golden_path_onboarding_success

• Saving a hypothesis? That’s just another tag - tag:hypothesis_validation_error

So instead of hopping between dashboards, everything happens in one place: the Search & Filter canvas. It’s the only view you need.

You investigate by stacking tags

Let’s say you’re trying to understand onboarding drop-off:

1. Start with sessions tagged issue: onboarding

2. Filter out noise: exclude sessions under 1min, remove internal testers

3. Notice a pattern: login problems. Tag those with cause:incorrect_credentials

4. Compare segments:

   • Group A: onboarding + login errors

   • Group B: onboarding – login errors

5. Save that as a hypothesis. Now you can track it, share it, and test it against metrics like hesitation, conversion, or time to goal.

Every step is saved and traceable

Because tags are saved to sessions:

• You never lose context

• You can always reload your exact filter stack

• You can share investigations like saved states - not screenshots

• Anyone on your team can pick up right where you left off

AI That Organizes Is What’s Actually Working

There’s a lot of noise right now about AI doing the work for you. But in practice, most of it breaks down on anything more complex than a one-step task.

What has quietly proven useful is AI that helps you stay organized, tagging, sorting, and structuring. Not replacing thinking, just making it easier to do.

That’s the pattern we’ve seen again and again. The tools that help you keep track, not take over, are the ones people keep using.

Subscribe now

Every partner is grappling with the same issue - post-deployment adoption.

To manage it, most rely on frequent check-ins:

“We meet weekly, sometimes twice a week, and work through issues with the client.”

It’s a reasonable approach when the client is small and the team is just 10–20 people. You can talk to everyone directly. You can keep a mental model of who’s struggling, what flows they’re using, and where the friction is.

But once the client scales to 50, 100, or 300+ users, that model breaks.

Weekly calls + surveys don’t scale.

They’re time-consuming, biased, and reactive. And while several partners reminded us that adoption isn’t technically their responsibility (it’s not in the contract), they also admitted that if adoption lags, the customer won’t be happy - so they end up doing it anyway to ensure satisfaction and retention.

Partners are responsible for delivery, but they’re judged (rightly) on adoption, and there’s no reliable, proactive way to see what’s actually happening across the org between meetings.

The gap we kept hearing

“We do lots of meetings.”

Good for relationships, bad for time.

They’re not targeted at the right employees, and you end up guessing which module/section is the problem - so the real blockers stay hidden and the quiet issues still get missed.

Reality: most partners run weekly / fortnightly / monthly check-ins and only speak with the manager (they can’t afford 1:1s with 50-300 employees). The manager then summarizes adoption issues - but they’re not seeing usage firsthand, so it’s biased and incomplete. Lots of struggles go unreported.

• “We run internal surveys.” Helpful, but slow to interpret, and often biased by who answers.
  
  Hidden assumption: this only works if managers have a reliable intake system to collect struggles from their teams. Most don’t; it’s ad-hoc Slack threads, forms no one fills, and anecdotes.
  

• “We’re responsible for success, but blind to the day-to-day.” Partners only hear about issues after they get loud.
  

• Retention is competitive. In a crowded partner market, proactive adoption is what keeps clients.

Why weekly calls and surveys don’t scale

• Limited coverage: A 45-minute call can’t tell you what’s happening across hundreds of users and dozens of workflows. You hear the loudest voice, not the full picture.

• High latency: By the time a problem makes it into a meeting, it’s already compounded. Friction becomes workaround. Confidence erodes. Recovery is slow.

• Manager filters & bias: Most check-ins run through one person, usually a manager, who isn’t watching usage. So they summarize what they think is happening. That’s often off.

• No precision: You don’t know who struggled or where. So you default to “invite everyone” training, not “train these 7 users on this exact step.”

• Rising cost, shallow truth: Fortnightly calls across accounts burn time and rarely surface ground truth.

• Reactive and guessy: Even if adoption isn’t your contractual responsibility, retention depends on it, so you’re on the hook, but flying blind.

What user analytics gives you instead

• Breadth over anecdotes: See patterns across all users, not just whoever joined the call.

• Precision: Spot the exact module, step, and cohort that’s struggling, and how badly.

• Prioritization: Triage based on reach (sessions/users) and impact (roles, goals, revenue risk).

• Fast, targeted fixes: Decide if it’s a bug, a UX flaw, or a training issue, and act accordingly.

• Proactive motion: Quiet failures like hesitation, loops, or workarounds don’t rely on someone speaking up. You spot and solve before they escalate.

What “good” looks like

To get a better understanding of adoption within Oodoo, you need a simple, repeatable motion:

1) Define “correct use” (Optimal Paths)

By module and role. Keep them versioned.

Examples:

• Purchase → Receipt → Putaway (move received items to storage bins) → Stock

• Sales Order → Invoice → Payment

2) Segment your cohorts

• Role (power users vs operators vs managers)

• Team/site (Warehouse A vs B; EU vs US)

• Tenure (new vs experienced).

3) Track four core signals

• Coverage - % of sessions/users touching a flow

• Completion - % finishing successfully

• Hesitation - pauses/loops/retries at a step (e.g., Validate, Confirm, Post)

• Workarounds - leaving the flow (export → spreadsheet → re-import) to “make it work”

4) Run a weekly adoption review (30-min prep → 30-min call)

• Before the call: sort by coverage × hesitation × completion drop; pick top 2–3 flows; assign likely cause: bug / UX-process / knowledge; propose an intervention.

• On the call: show what happened, who’s affected, why, and what we’ll do; confirm owners & timelines.

5) Match the fix to the cause

• Bug → ticket with repro + before/after impact

• UX / process → simplify steps, clarify microcopy, remove dead-ends

• Knowledge → targeted training for named users on named steps (don’t invite 50 people)

6) Close the loop next week

Re-check the same flow: hesitation down? completion up? coverage back on path? If not, revisit the cause.

If you’re starting from zero, a clean spreadsheet beats a stack of meeting notes: flow/step, module, role, completion flag, time-to-complete, hesitation proxy, workaround tag, user/session counts.

What to look for each week (signals that matter)

• Workflow drifts: skipping, backtracking, or long detours in core flows

• Hesitation spikes: pause → re-try → hover-backtrack on steps like Validate / Confirm / Post

• Dead-ends & rage clicks: repeat clicks on disabled/blocked elements

• Workarounds: leaving native flows to “hack” completion elsewhere

• Outlier time-to-complete: steps or cohorts much slower than peers

• Form friction & errors: repeated corrections/validation failures on the same fields

• Cohort concentration: specific roles/sites disproportionately affected

Triage → Intervention → Proof. That’s the loop.

If you want to compress the time: where Autoplay helps

Use the playbook above with any stack. Autoplay just makes it faster and less guessy by turning raw usage into actionable signals per module, per flow, per cohort:

• Issue Dashboard (weekly starting point): automatically surfaces top friction patterns by module/flow/cohort with cluster stats (e.g., Sessions: 68 · Coverage: 32.5% · Unique Users: 3 · Hesitation Score: 29).

  

• Golden Paths: define once; see exactly where users deviate or hesitate.
  

  

• Intent / knowledge / hesitation: UI-aware analysis of what users tried to do, where they got stuck, and why (bug vs UX/process vs knowledge).

• Clusters, not one-offs: fix patterns instead of chasing individual replays.

• Agentic Q&A (Perplexity Flow): ask, “Which module spiked this week?” “Bug or knowledge gap?” “Which power users are blocked?” and get scoped answers with evidence.

  

• Real-time chat assist: when someone hovers/loops/asks the bot, Autoplay inspects the prior interactions, matches similar successful sessions, and guides them through Odoo’s UI in context - proactive, not generic.

What a better weekly actually looks like

30 minutes before the call:

• Open the Issue Dashboard → review the top 3 clusters by coverage.

• Note high-hesitation modules (e.g., Inventory > Stock Moves).

• Ask: “What’s the likely cause for Cluster #1?”
  → Knowledge gap in Putaway for warehouse power users; repeated hover-backtrack on Validate.

• Ask: “Any bug signatures?”
  → Compare before/after windows; flag real defects if present.

• Decide the intervention:

  • Bug (ticket)

  • UX (microcopy/flow tweak)

  • Knowledge (targeted training for named cohorts).

Walk into the call with:

• The issues that matter

• The users affected

• The cause

• The recommended fix.

One weekly, not two. Less guessing, more outcomes.

Why this matters to Odoo partners

• Proactive retention: show up with evidence, not anecdotes - what broke, where, for whom.

• Targeted training (instant ROI): identify which users are struggling and on which step inside which module; don’t pull everyone into a generic session.

• Fewer internal meetings: replace “let’s ask everyone” with “here’s what’s happening,” plus named cohorts to address.

• Less bias, more truth: behavior + intent beats manager summaries and survey guesswork.

• Clear accountability: tie issues to modules, flows, and specific users; ship the fix; close the loop next week.

A quick scenario

• Observation: Inventory shows 32% of sessions deviating at Putaway (moving received items into their storage bins).

• Cause: No defect. Users hover → backtrack on Validate. Knowledge gap.

• Action: 30-minute micro-training for warehouse power users + inline copy tweak.

• Follow-up: Next week, hesitation drops; completion rises. Done.
  (Compare that to two calls of “what’s not working?” plus a survey no one reads.)

In short:

Weekly calls and surveys might keep the relationship warm - but they won’t show you who’s stuck, where, or why. Adoption is the real metric, and you can’t fix what you can’t see. The partners who win are the ones who move faster, with precision. Not more meetings - just better ones, built on evidence.

Leave a comment

Subscribe now

You hear about a plane crash and suddenly flying feels risky - even though it’s statistically the safest way to travel.

Nothing changed about reality - your brain just latched onto something vivid.

This shows up all the time in customer interviews.

You speak to a user who tells a compelling story about a painful experience with your product. It’s detailed. It’s emotional. It sticks in your mind. And suddenly, you’re prioritizing it like it’s a systemic issue.

But is it?

Where availability bias skews product priorities

This is where things get expensive. You might:

• Shipping a major feature overhaul to fix a problem that only 4 users have

• Ignoring a small UI tweak that’s confusing hundreds of people a little bit every day

You feel like you’re solving something important, but you’re actually just solving something memorable.

Loud ≠ common. And intensity of pain isn’t the same as breadth of impact.

What matters is how many users it affects, and which users.

How to check yourself

Before jumping to solutions, ask:

• Is this representative? Who am I actually speaking to?

• Is it confirmed elsewhere? Can I find this issue in analytics or session data?

• Am I leading them? Are my questions loaded with assumptions or fishing for a specific answer?

Because if your inputs are biased, your roadmap will be too.

Who should you be listening to?

Customer interviews aren’t useless - they just need context. Here’s how to avoid the bias and make them useful:

1. Start by defining your cohort

Not all users are equal. A power user with high LTV or expansion potential should absolutely get more weight than a free-tier lurker. Before you even run an interview, know:

• What plan they’re on

• How active they are

• Their role and team size

• Their potential to expand or churn

You’re not just validating problems - you’re validating them for the right user type.

2. Don’t mistake a good story for good data

Ask yourself:

• Is this the first time I’ve heard this issue?

• Are they describing something measurable (a drop-off, bounce, hesitation)?
  Are they generalizing (“everyone on my team struggles”) or just speaking personally?

Record your interviews, transcribe them, tag specific quotes - and always cross-check them with behavior.

3. Use session data to verify it

Let’s say a user complains about a confusing part of onboarding.

With Autoplay, you can:

• Pull up that user’s session

• Tag the friction point

• Check how many other users hit the same blocker

• Slice it by cohort, is this just new users? Just self-serve accounts? Just EU customers?

Now you’re not just taking someone’s word for it - you’re seeing how widespread the problem really is.

Qual + quant: how to make decisions that scale

To know if feedback is valid (and worth prioritizing), run it through both lenses:

Qualitative

• User interviews

• In-app feedback forms

• Support tickets and chat transcripts
  

Quantitative

• Session replays

• Drop-off analysis

• Click maps and scroll depth

• Funnel conversion

• Tag frequency in Autoplay
  

Example:

• 3 power users complain about the export feature - all high LTV, all churn risk.

• Only 5% of all users use that feature, but 80% of enterprise accounts do. That’s a fix worth prioritizing.
  

Don’t let one user set the roadmap

Interviews are a signal, not a decision.

Use them to generate hypotheses, not conclusions. Always verify with behavior, and always ask: how many users is this really affecting?

And which ones?

Availability bias makes you think you’re being user-centric, when really, you’re just being reactive.

Final thought

Not every loud complaint is a sign of a big problem.

And not every small annoyance is insignificant.

Listen to your users. But don’t let one vivid story speak for all of them.

Subscribe now

I get to roast some companies’ onboarding experience, test autoplays’ AI insights and send a feedback loop to my AI engineering team - TRIPLE win.

🚀 Onboarding Roast or Toast:
⏱️ 5 minutes per tool + self recording
🎯 One clear intention.
📹 Documented Burns + Earns.

Last week’s intention:

Find a provider to build an AI-powered chatbot trained on my help center.

Intercom

Burns:

• I got frustrated by the page loading time at the start.

• I got confused on submitting my url for the knowledge base.

• The onboarding checklist was only accessible from the homepage. When I needed a reminder of the next step, tab-switching created disorientation and broke my flow.

• The ”guidance” section on configuring the chatbot tone was confusing. I couldn’t tell if tone was applied globally or to certain customers. Without more context or walkthroughs, I was left second-guessing.
  

Earns:

• The checklist itself was great - showed me what was possible and gave a clear picture of the journey ahead.

• The UI quickly aligned with my intention: setting up an AI-powered chatbot on my knowledge base.

Did I Get to Value?
No

Autoplay Analysis:

(https://lnkd.in/dqTqgxkr)

Burns:

• It didn’t pick up that I got confused on the "Guidance" section and that the "Guidance" section UI is what threw me off and caused me to go back to the home page to re-orient myself.

Earns:

• It picked up that the loading time of page responsiveness caused frustrations on my end: “The user exhibited impatience during loading sequences by clicking on new sections before the previous one had fully loaded”.

• It picked up that I was struggling with submitting my URL: “The user might have been unsure about the precise format or correct URL needed for synchronization”.
  
  

Crisp IM

Burns:

• I couldn’t upload a simple URL to create my knowledge base. That’s all I wanted: to drop in a url link and go. But I couldn’t get it to work.

• I was taken to the workflow section before I even had a v0 of my chatbot set up.
  

Earns:

• They asked about my intentions at the very start, so the flow felt personalized from the beginning.

• I loved that the onboarding checklist was available everywhere. I always knew what I could do next and in what order.

Did I Get to Value?
No

Autoplay Analysis:

(https://lnkd.in/dNgCUDFG)

Burns:

:)

Earns:

• It understood that the url submission is what prevented me from completing my task: “When attempting to import content into their knowledge base via URL, the user was prevented from proceeding by a system error stating that a custom domain was required”.
  

The onboarding flow I would have loved instead:

1. Login

2. Select/write my intention

3. Submit the url of my help-center for the chatbots’ knowledge base

4. Immediately interact with the chatbot trained on my knowledge base to get a feel for it and understand how its responding

5. Only then start to customize tone and response format etc

This triggered some interesting ideas linked back to Autoplays’ offering:

Currently Autoplay works backwards from your action sequences on software and compares them with similar users to infer your intent out of all the 1….n possible intentions in the software.

But we could boost its speed and accuracy by integrating with the intention forms you fill out during onboarding - so the AI instantly knows exactly what you’re trying to do.

This would give the AI more context, and feed the real-time copilot instant intention data to steer the user in the right direction on the software.

Autoplay could also work faster once it locks in your goal, spotting friction points and tailoring everything to your specified intention.

Any thoughts? Feel free to drop them in the comments below :)

Leave a comment

Subscribe now