Give users a reason to sign up

When someone lands on a SaaS website, we tend to behave as though their next decision is whether to create an account, when quite often they are still trying to work out whether the product solves the problem that brought them there. We ask for their email, company name and role, then introduce a dashboard full of concepts they have never encountered, with the expectation that a welcome tour will connect all of this to something they actually care about.

At Noodle Seed, we approach agentic onboarding as a way to close the gap between what a visitor needs to understand and what the product asks them to do. Before we make signup easier, we need to give someone a reason to sign up, preferably by helping them make progress on the problem they came with.

Agentic onboarding lets an embedded assistant explain relevant product capabilities, clarify a customer's intent, and carry out a permitted next step. The opportunity is a product that can explain itself in the context of someone's work, then help them begin that work once they are ready and have given it permission.

The problem starts before the welcome screen

There is no single reliable number for how many SaaS users struggle with onboarding, although there are useful signals. In a survey of 216 people conducted in early 2020, Wyzowl found that 80% had deleted an app because they did not know how to use it. That is a small, older consumer survey, not evidence that 80% of B2B SaaS users abandon onboarding, but it captures a recognisable failure: a product can be available to someone without being understandable to them. Wyzowl's onboarding research

Amplitude's Product Benchmark Report offers a different perspective, finding that 69% of products in the top quartile for seven-day activation were also in the top quartile for three-month retention. Its activation measure is a return visit on a specified day, rather than completion of a business task, and the relationship is correlational. Even with those qualifications, it gives product teams a reason to take the early experience seriously alongside acquisition. Amplitude's benchmark report

For a founder, this is an expensive place to lose someone because the work of getting their attention has already happened. For an engineering team, it is frustrating because the capability may already exist, sitting behind terminology, setup decisions or a sequence of screens that the visitor has not yet learned to navigate.

The psychological burden is easy to underestimate when you know your own product. A new user is trying to understand unfamiliar concepts, decide whether the product is relevant, and judge the consequences of their next action, sometimes while being asked to connect company data or invite colleagues. A progress bar tells them how much setup remains, but it does very little to explain whether finishing it will be worthwhile.

Nielsen Norman Group's usability research on login walls describes a related problem: asking people to register before they have enough information to judge the value of doing so. In B2B software, the uncertainty can extend beyond an email address to questions about data access, organisational permissions and whether someone is about to change a real business process. NN/G's research on login walls

Good onboarding needs to reduce that uncertainty as well as the number of clicks.

Give the conversation something useful to do

Consider an operations manager evaluating an expense platform who types:

“We have twelve people, and I want expenses above £5,000 to go through finance. Can this handle that?”

An assistant that responds with a feature description and a signup link has answered the question, but it has left most of the work with the visitor. A more useful response would explain how the approval rule works and ask the one question that changes its configuration:

“Yes. Should finance approve those expenses after the person's manager, or instead of their manager?”

Once the visitor answers, the product could show a sample policy: expenses up to £5,000 need manager approval, while anything above that amount needs both manager and finance approval, in that order. The visitor can inspect and correct the proposal without learning where approval conditions live in the settings menu.

This is education through a relevant example, with a visible result that helps someone judge whether the product understands their situation. It also gives signup a specific purpose:

“This is a preview; nothing has been saved or sent. Create a workspace to save this policy, then choose who should approve expenses.”

The account request now follows something the visitor has chosen to continue. Someone who is still evaluating can keep asking questions, while someone ready to proceed knows what creating an account will enable.

Chat-first should still leave room for cards, buttons and conventional controls. Comparing two approval paths is often easier visually, and selecting a workspace from a list is usually better than typing its name. The conversation supplies context; the interface should use whichever interaction makes the next decision clearest.

Building the experience with Noodle Seed

Noodle Seed provides the embedded assistant and a way to expose product knowledge and typed actions through a shared runtime. Your application supplies the business operations, permissions and saved state that make the conversation useful.

For someone evaluating Noodle Seed itself, the first conversation should establish which customer workflow they want to support, explain how an assistant would fit into their existing product, and make the implementation boundary clear. The reason to create an account is to begin building that experience for their own customers, with a concrete first workflow in mind.

The architecture starts by separating what an anonymous visitor can learn from what an authenticated user can do. This abbreviated example adapts our reference implementation for a fictional company, Acme, using Noodle Seed's TypeScript authoring API; the referenced knowledge and tools are defined elsewhere in the app.

const assistant = embeddedAssistant({
  model: noodleManaged(),
  access: [
    publicWebsite({
      origins: ['https://acme.example'],
      capabilities: [
        product,
        showProductPath,
        myOnboardingStatus,
      ],
      signIn: true,
    }),
    authenticatedWebsite({
      origins: ['https://app.acme.example'],
      capabilities: [
        product,
        myOnboardingStatus,
        createFirstApp,
      ],
    }),
  ],
});

The public surface can explain the product and show a relevant path. In this implementation, requesting the identity-dependent onboarding status prompts an anonymous visitor to authenticate before it can run; listing the capability does not give the visitor access to private data. The signed-in surface separately exposes the first-app action.

Your existing authentication system still verifies the user. The host application handles the sign-in transition, and its backend establishes the authenticated assistant session using verified identity; a browser-provided email address or a sentence in the conversation cannot grant authority.

The UX detail that matters here is continuity. After signing in, the user should return to the task they were discussing, with a clear explanation of what is now possible. Noodle Seed's cross-site continuation support can carry bounded conversation history across that transition, while the application remains responsible for securely saving and recovering any actual draft. Remembering a proposed policy in chat is different from persisting it as an editable business object.

Let the assistant act, with the user in control

The next step is to expose a small, useful operation with a defined input, a result the application can verify, and a confirmation boundary appropriate to the action. In our onboarding reference, that operation creates a minimal starter app:

const createFirstApp = tool('create_first_app', {
  title: 'Create my first app',
  description: 'Deploy a minimal starter app after confirmation.',
  annotations: annotations.openAction({
    destructive: false,
    confirm: true,
  }),
  input: z.object({
    org: z.string().min(1).max(63),
    app: z.string().regex(/^[a-z][a-z0-9]{2,29}$/),
  }),
  output: z.object({ ok: z.boolean() }),
  fulfil: ({ input, connectors }) => {
    const result = connectors.cloud.deployStarterApp({
      org: input.org,
      app: input.app,
    });
    return { ok: result.ok as boolean };
  },
});

This shortened example omits the connector configuration and additional result fields. The declaration makes confirmation part of the action contract, while the backend must still validate workspace access and enforce the user's permissions. Before execution, the interface should show what will be created and where; afterwards, the assistant should describe the verified result, including failures, without claiming success simply because it attempted a tool call.

For an expense platform, the equivalent operation might save the reviewed approval policy. Publishing it, inviting colleagues or changing a live workflow may require separate permission and confirmation, because agreeing that an example looks right is not consent to every subsequent action.

Building this well therefore involves more than embedding a chat window. You need reviewed product knowledge, narrowly defined actions connected to your existing APIs, appropriate public and authenticated surfaces, and recovery paths for cancelled sign-in, expired sessions and failed operations. If the assistant cannot finish something, the user should be able to continue in the conventional interface without losing their work.

Our own reference implementation connects public product education with identity-gated onboarding and a confirmed first action. The examples here explain that capability and its design, rather than a claim of measured conversion improvement.

Measure the work that follows signup

A longer conversation does not necessarily mean better onboarding, and a successfully created account does not tell you whether the product delivered value. For Noodle Seed, deploying a starter app is a setup milestone; the stronger outcome is a customer's user successfully completing a useful, permitted workflow.

I would evaluate this experience against the existing onboarding path using time to first useful result, successful task completion, subsequent usage and support demand, alongside abandonment, errors and the cost of running the assistant. Those measures help distinguish an engaging conversation from an experience that actually improves the business.

The place to start is one workflow that people already struggle to understand, with enough public explanation to establish its value and one permissioned action that helps them begin. As that path becomes reliable, you have a basis for expanding the assistant's role without asking users to trust it with the whole product at once.

Before adding another field to the signup form, I would ask what we could help someone understand or accomplish before they reach it. If the product can answer that question through the experience itself, creating an account becomes a continuation of something useful they have already started.

Start with one customer workflow

Choose a task your customers already ask for help completing, then identify what they can safely explore before signup and which action genuinely needs an account. Build that path with your existing product APIs and verify the result before expanding the assistant's permissions.

Explore the developer guide to start building an embedded experience with Noodle Seed.