SaaS empty states that teach customers what to do next

An empty state appears when a person opens a list, report or workspace with nothing to show. That person usually has a goal: find a record, confirm a connection, start a task or understand what happens next. The screen is a temporary obstacle, not a reason to make the visitor guess.

Common lines such as “Nothing here,” “No data available” or “Oops, something went wrong” report the interface’s condition but leave the customer’s problem untouched. They can make routine setup feel like failure and train people to distrust the product.

Useful empty-state copy does three jobs quietly: identify what is missing, explain why it is missing and offer the most credible next move. It should feel calm, specific and proportionate. A user should know whether to create, filter, reconnect, request access or wait.

The same principle changes across the journey. A first-use dashboard needs teaching, a filtered table needs orientation, and a failed integration needs recovery. Crafting SaaS empty state copy that teaches instead of apologizes means writing from the customer’s unfinished goal rather than the database’s status.

Start with the user’s unfinished goal

Before choosing words, define the moment the state represents. Is this a new account, a cleared list, an active filter, a restricted area or a service that has not responded? Each cause requires different language and a different action.

A useful content specification records the trigger, available data, user permission, expected recovery and primary task. It also states what the product should never reveal. That last point prevents an empty search from implying that hidden records exist for someone who cannot access them.

For a filtered invoice list, for example, the heading can say “No invoices match these filters.” The body can say, “Try a wider date range or clear the status filter.” “Clear filters” tells the user exactly what to press. Three short elements turn uncertainty into a solvable task.

Turn absence into a clear sequence

An empty state often works best as a sequence: name the condition, connect it to the customer’s goal, then provide an action. “Your project list is empty” is accurate but passive. “Create a project to track tasks, files and milestones” explains why the space matters.

Keep the primary action specific. “Create project” is stronger than “Get started” because it names the result. Use a secondary action only when there is a genuine choice, such as “Import from CSV” beside “Create project”. Too many routes recreate the cognitive overload the screen was meant to remove.

On a first-use screen, show the smallest valuable outcome rather than a tour of every feature. On a populated account with no results, teach filtering instead of onboarding. Match the depth of the explanation to the user’s intent: one sentence for a simple action, a short sequence for a multi-step setup.

Distinguish empty, unavailable and unauthorised

Empty, unavailable and unauthorised are different states, even when they share a blank canvas. Zero data means the account has no items. No results means the query worked but found nothing. Unavailable means the product cannot currently load or reveal the information. Each needs its own heading, body and recovery path.

Do not disguise a technical error as an empty state. “No reports are available” conceals a failed request; “Reports could not load because the connection timed out. Retry now” tells the user what happened and what to do. For a permissions state, avoid confirming the existence of protected data. Say, “Billing records require an owner or admin role. Ask an account owner for access.”

The interface should also distinguish a lasting block from a temporary delay. A disconnected integration can offer “Reconnect accounting system”, while a background job can say, “Your first import is still processing. We’ll update this page when it finishes.” Calm wording reduces uncertainty without inventing a cause.

Replace product jargon with plain guidance

Product language often leaks into empty states: “No webhook events are queued,” “No objects match this query” or “No authorised resources found.” Replace internal nouns with the user’s task. Name the object in plain language, then explain the condition in terms of what the person expected to happen.

The editing process in simplifying technical jargon applies directly here. Define an unavoidable technical term once, then use familiar language everywhere else. A webhook explanation might say, “No incoming events have arrived yet. Check that your app is sending data to the correct connection.” The product can retain the precise term in help content.

Read every line aloud and remove duplicate instructions. If the heading says there are no invoices, the body should not begin by repeating “There are currently no invoices”. The heading names the condition; the body explains the next move. This small division keeps scanning easy and gives screen-reader users a clear hierarchy.

Build copy for Australian contexts

For analytics and support tools used by teams distributed across Sydney, Melbourne and Brisbane, timestamps need context. “Updated at 9:42” becomes useful only when the interface also identifies the zone, such as AEST or AEDT. Support copy can mention the business day, while scheduling tools should expose the selected timezone beside the time.

Australian date and reporting conventions deserve equal care. Use day, month and year when ambiguity is possible, and account for the Australian financial year when a report is framed by financial periods. Empty date filters should state which convention applies instead of forcing users to infer it from placeholders.

Pricing and market expectations also belong in the copy. Australian B2B SaaS buyers often assess transparent costs, dependable support and security controls, so a billing dead end should not hide the next step. Where amounts are shown, identify Australian dollars and whether GST is included; a blank invoice page can direct customers to a clear billing history or payment method.

For products handling personal information, the Privacy Act 1988, Australian Privacy Principles and Notifiable Data Breaches scheme shape responsible guidance. A restricted state should provide a legitimate access route without disclosing protected records. An incident state should give factual status, relevant timestamps and a support contact, rather than reassuring language that the product cannot support.

Everyday connectivity shapes the reading experience too. People open B2B tools on phones during Sydney train journeys or Melbourne tram commutes, sometimes with an unstable connection. Front-load the action, keep the explanation brief and distinguish offline, syncing and failed states so a patchy signal does not look like lost work.

Test states as real product journeys

Test empty states as journeys rather than isolated strings. Build a matrix of personas, account ages, filters, permissions, devices and connection conditions. Include first-time users, experienced administrators and people using assistive technology, since the same state can block each group differently.

Give testers a task, not a preference question. Can they identify what is missing, choose the right action and recover without support? Observe where they hesitate, return to the page or invent another route. Behaviour exposes confusion that a simple copy review can miss.

Measure action completion, repeated clicks, support contacts and the rate at which users abandon the surrounding workflow. Pair those signals with short interviews. Review states after product releases, because a renamed feature, changed permission model or new integration can make accurate copy outdated within weeks.

Create a reusable messaging system

A scalable system gives every team a pattern. Define the required elements—heading, explanation, primary action and optional recovery help—then provide approved examples for creation, zero results, permissions and failure. This creates consistency without flattening the differences between contexts.

Guidance should narrow choices instead of transferring the entire problem to the reader. Even outside interface copy, this hosting provider comparison models the value of specificity by sorting a complex purchase through location, support and reliability rather than returning an unexplained list of options.

Treat copy defects like product defects. Give product, design, support and content owners a shared inventory, an owner for each state and a review trigger. When one team improves a screen, the pattern can travel to onboarding emails, pricing pages, advertising claims and help-centre articles without creating seven versions of the same promise.

Empty states are small messages inside decisive product moments. SaaS Minds, led by Victoria Rudi, helps B2B SaaS teams simplify and refine messaging across websites, advertising, pricing pages, onboarding emails, help centres and other customer touchpoints. Support can be embedded, full-time messaging expertise or focused, project-based work shaped around a specific communication problem.

Bring the highest-traffic empty states, their underlying triggers and the questions customers ask support to SaaS Minds. Turn each blank canvas into clear guidance, a credible next action and a narrative that feels consistent across the product.