Writing the Empty-State Prompt in B2B SaaS Products

A user logs in for the first time and the screen shows nothing. That blank moment is the highest-stakes sentence in a B2B SaaS product, higher than the landing page, higher than anything in the sales deck, because by the time someone hits an empty state, acquisition is already done. They signed up, handed over an email, maybe a credit card. Attention is the scarce resource now, and most teams still treat this screen like a design afterthought instead of recognizing it as a writing challenge.

The math makes the stakes concrete. Take 1,000 monthly signups at $100 ARPU. If roughly 80% abandon in the first week due to activation failure, that's 750 users gone from a single month's cohort. At $100 ARPU, that's $900,000 in potential ARR lost, because three sentences on one screen failed to do their job.

Not all empty states are equal, where the stakes are highest

Empty states appear throughout a product's life, not just on day one. A first-time dashboard has no data yet, and that's where friction runs highest. A user-cleared state, every task done, every item deleted, can feel like a small win if the copy plays it that way. Search results can come back empty, leaving the user with a question mark instead of an answer. Errors and 404s hit when the system fails to load, and if the copy reads like a wall, trust takes the damage. Feature-specific empty states appear when someone hasn't touched a particular tool yet, common in freemium and product-led products. Permission-denied screens hit when someone runs into a wall they can't get past, and the copy there either opens a door or kills curiosity. Filtered-to-nothing states happen when a user's own filters return zero results, and that needs an explanation.

The first-run dashboard carries the most weight of all of these. It's the moment someone decides whether this product deserves more of their time. Almost every other empty state is recoverable. This one usually isn't, and treating it with the same casual attention given to a filtered-search screen is where most teams get the priority backwards. Teams that spend three sprints polishing an empty search-results screen while shipping a blank first-run dashboard have their whole roadmap upside down.

The writing has to flex by type. A zero-results search screen needs to redirect, fast. A first-run dashboard needs to orient someone who has no mental map yet. A completed-tasks screen can afford a little warmth, even a small celebration. But three questions, what is this, why now, what next, apply no matter which flavor of empty state a person lands on.

What the three questions demand from the writer

The headline's only job is answering "what is this?" Not "No data found." Not "Empty." Those two phrases answer nothing, and they leave the user to do the work the product should be doing for them.

Take a workspace with no channels yet. The weak version says "No channels." The strong version says something closer to "You're in. Let's create your first channel." That single line orients the user instead of describing an absence. One sentence should be enough, and if someone has to guess what the screen is for, the headline already failed.

The second question, why this matters to this person right now, needs a supporting line, two sentences at most. Most teams skip this step entirely, and the empty state ends up reading cold, like a system message instead of a product talking to a person. The supporting line has one job: bridge what the feature does to what the user is actually trying to accomplish. Not a feature description, a statement of value, tied to this exact moment. Role matters here too. An admin setting up a workspace needs a different "why now" than a contributor who just got invited into one.

What someone should do next comes down to one primary call to action, never three competing ones. "Create your first project." "Connect a data source." "Invite a teammate." Each of those is a complete instruction on its own. Decision paralysis is the real enemy here: uncertainty about what the screen is, what to do, and whether something's broken compounds quickly, and each unanswered question raises the likelihood of abandonment. The verb choice matters more than it looks, too. Action verbs tied to an outcome, like "Run your first report," beat generic label verbs like "Get started" almost every time, because they tell the user what they'll walk away with.

Illustration, the fourth element people tend to obsess over, is genuinely optional. If it takes weeks to produce or doesn't fit the brand, skip it and ship. The headline and the CTA do the actual activation work. The illustration just sits on top of that, and teams that spend a design sprint on custom empty-state art while the headline still reads "No data" have their priorities backwards too.

How Slack and Notion answer the three questions without a word of instruction

Slack doesn't leave a new workspace looking empty. Slackbot sends real messages, and the general channel opens with a welcome thread the moment someone logs in. The user can reply, react, drop in a file, all before a single teammate has joined. Nobody has to read a tutorial to figure out what Slack is for. The product lets them feel it instead.

Notice what that setup answers without a single instructional sentence. What is this? A place where conversations happen, obviously, because one is already happening. Why now? The workspace is ready, so there's no reason to wait. What next? Reply to the message sitting right there. Copy and populated content aren't separate jobs here. When the product demonstrates itself, the words don't have to explain it.

Notion runs a different but related play. It doesn't open on a tutorial. It opens on a template gallery, meeting notes, a product roadmap, a personal CRM, and the user lands inside an already-populated document. Notion's block model gets taught through interaction, not tooltip tours nobody reads past the second step.

The label on each template is doing the copywriting. "Product Roadmap" tells a user what they're about to get, and picking it is itself the call to action, no separate button required. What is this? A blank canvas that turns into a real document. Why now? Pick the structure that matches the goal already in someone's head. What next? Choose a template and start typing.

Both products point to the same underlying move: populate the empty state with content that simulates real use, so the user builds muscle memory before anyone else even shows up. For products with a steeper learning curve, where value only appears once real data gets connected, the sharper move is a demo sandbox. Dropping the user into an environment that already looks full skips the empty state entirely, since there's never a blank screen to fill.

Different empty states for different people

Generic onboarding, the same flow for every kind of user, ranks among the top reasons SaaS onboarding fails inside the first week. A platform with five distinct user roles can't run all five through one identical script. Running them through one anyway is the default mistake, and it's the wrong call every time a product has more than one type of buyer. Enterprise products that treat every signup as having the same goals, the same technical comfort, and the same amount of free time end up failing most of them, not by a small margin, by the majority.

Three signals can fork that experience. Role or persona declared at signup, admin versus contributor versus analyst, is the first. Plan or configuration state already sitting in the database, what the account has set up, what it hasn't touched, is the second. Prior behavior, which pages got visited, what got clicked, what got skipped, is the third.

A short micro-survey dropped right at the empty state, asking about role or goal, supplies enough context to split the onboarding path and tailor both the guidance and the CTA that follows. It just needs to exist. It just needs to exist.

Why PLG products feel this problem more acutely than sales-led ones

Product-led growth has become a widely adopted strategy among B2B companies, with growth built around in-product signals like feature adoption and time to value, with the State of Digital Analytics report drawing on data across more than 12,000 companies. Roughly 58% of B2B SaaS companies run some version of PLG, according to the State of Digital Analytics report. Only 34% actually track activation. That gap, enthusiasm for PLG outpacing the discipline to measure it, is where a lot of companies quietly get stuck.

In a sales-led motion, confusion has an exit ramp: call the rep, ask the question, get walked through it. PLG has no rep waiting on the other end of that blank screen. The product has to do, in that exact moment, the job a salesperson would otherwise be doing.

Activation deserves a precise definition here, since it's neither login nor a page view. Activation is the first action a user completes that predicts they'll stick around long-term. The empty state sits directly in front of that moment, as its gatekeeper, and copy that fumbles the three questions is a closed gate no amount of downstream nurturing can reopen.

The onboarding UX patterns that work alongside the empty-state prompt

The empty state doesn't operate alone. It works inside a larger set of onboarding patterns, each doing a distinct job, and confusing one for another is a common failure mode on its own.

Welcome messages orient a user to the product's purpose right after signup, before they've even reached the empty state. Onboarding surveys collect the role and goal data that forks the experience, feeding the personalization signal covered above. Onboarding checklists give users a visible map between where they are and where value actually shows up, and that visibility keeps onboarding from feeling like an open-ended chore. Tooltips and hotspots offer contextual guidance right at the point of confusion, but they belong after the empty state gets resolved, not during it. Modals and banners work well for announcing new features once someone's already activated. Self-help resource centers catch users who get stuck later on, though they're a poor substitute for a clear empty state. Leaning on a help center instead of fixing the screen leaves the underlying confusion sitting exactly where it was.

Users who get stuck early rarely go looking for a help center on their own. Contextual help, placed exactly where the confusion happens, addresses the problem directly rather than routing users away from the screen where they got stuck. A progress bar works the same way: it acts as a small commitment device, one that keeps onboarding from feeling infinite. The empty state's CTA does its best work when it leads somewhere visible and specific, never into another blank canvas.

Progressive disclosure, the practice of hiding complexity until someone's actually ready for it, is what makes the three-question framework hold up under real use. Because it hides complexity until people are ready for it, the framework only has to answer what a user needs at that specific moment, not everything the product can eventually do. The empty state doesn't need to answer every question a user might have somewhere down the line. It needs to answer the three that matter in that exact second.

How behavior signals and database state improve empty-state copy over time

Most empty states are static. They say the identical thing to every user, regardless of plan, role, or what that person has already done inside the product. That's a bigger gap than most teams admit, and it's a fixable one.

Closing it means combining two data sources. Current database state, plan, role, configuration, what's been set up and what hasn't, tells the product where an account stands structurally. Behavioral data, what actions got taken, what got skipped, tells the product what this specific person is actually doing with their time. Neither one alone is enough, but combined, they show what someone needs next with real precision.

Personalized onboarding flows and feature adoption campaigns already adapt based on real user behavior. Empty-state copy should run on the same logic, and most of it currently doesn't. The CTA for a user who has already taken some steps should look nothing like the CTA for someone who hasn't started yet, and shipping the same line to both is a missed signal sitting right in the database.

Measuring an empty state's effectiveness also needs the right denominator. The relevant group is the users who reached that screen in a state where acting on the CTA was actually possible, not everyone who ever signed up. Measuring against total signups instead inflates the failure rate and obscures what the copy is actually doing for the people it was written for.