> ## Documentation Index
> Fetch the complete documentation index at: https://studio.assembly.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Driving adoption

The first session brings clients in. Adoption is what keeps them coming back. The work here isn't about features — it's about communication design, notification discipline, and the willingness to ask what's not working.

## The two failure modes

Almost every adoption problem reduces to one of two patterns:

<Tabs>
  <Tab title="Silence">
    Clients sign in once, never come back, and don't reply when you ask why. The Portal is technically working but it's invisible to them.

    Fix: more touches. Send Portal-based messages instead of email. Use in-product notifications for routine updates. Make the Portal the surface where things happen, not a place they have to remember to check.
  </Tab>

  <Tab title="Noise">
    Clients sign in often but tell you the Portal is overwhelming, too busy, too noisy. They start ignoring notifications.

    Fix: cut emails first. Cut notifications second. Default to in-product where possible. Make sure every email is one a client would want to receive — would you forward this to a friend? If not, it shouldn't be auto-sending.
  </Tab>
</Tabs>

Most firms err on the side of noise, then panic, then over-correct to silence. Aim for the middle: enough signal that clients know something happened, not so much that they tune out.

## Notification strategy

A few rules that hold up across firms:

<Check>
  In-product for routine. A status change, a new document, a completed step. Clients see it next time they visit.
</Check>

<Check>
  Email for things you need them to see soon. A new request awaiting their action, an invoice due in 24 hours, a contract that needs signing.
</Check>

<Check>
  Never both. If something is in-product, don't also email it. Pick one channel per event.
</Check>

<Check>
  Batch where you can. A daily digest beats five emails at 9am, 10am, 11am, noon, and 2pm.
</Check>

When you build a new app, the planning step asks about notifications. Be deliberate. The default plan tends toward more notifications than you'll want in production.

## Moving comms out of email

The slow shift from "we use email + Assembly Studio" to "we use Assembly Studio + email as fallback" is what unlocks the Portal's value. A few moves that help:

* Stop attaching files to emails. Upload them to the Portal and link there.
* Stop sending status updates by email. Update the status in the relevant app and let the notification fire.
* When a client emails you, reply in the Portal Message thread and mention you'll respond there from now on.
* Make the Portal URL part of your email signature.

The goal isn't email purity. It's making the Portal the obvious first place to look.

## Getting feedback

You'll learn more from a 15-minute call with three clients than from any analytics dashboard. The questions that produce useful answers:

<AccordionGroup>
  <Accordion title="What did you check the Portal for the last time you signed in?">
    Reveals the actual reasons they show up vs. the reasons you think they show up.
  </Accordion>

  <Accordion title="What's something you wish was in the Portal that isn't?">
    Surfaces gaps in your app coverage. Often the answer is a workflow you currently handle over email.
  </Accordion>

  <Accordion title="What's something you find confusing or annoying?">
    The unprompted complaints are the ones worth fixing. If multiple clients say the same thing, it's not a one-off.
  </Accordion>

  <Accordion title="What would make you sign in more often?">
    Sometimes the answer is content (more updates, more visible progress). Sometimes it's a feature. Sometimes it's a notification that's currently missing.
  </Accordion>
</AccordionGroup>

## When iteration is the right move

Adoption problems often look like product problems but feel like communication problems. Both fixes are valid. A signal it's time to iterate on the app itself:

* Multiple clients struggle with the same thing
* The thing is in the app, not in how you've talked about it
* A small change to the app would meaningfully improve the first session

If that's the case, head back to the build chat and iterate. See [Iterating on apps](/docs/building-new-apps/iterating-on-apps) for the workflow.

<Tip>
  Treat your first ten clients as your beta. Don't expect everything to land. Expect feedback. The apps you build in your second month will be much better than the ones you built in your first, because you'll know what your clients actually wanted.
</Tip>