A user in Auckland sees a push notification about a new SaaS feature, swipes it away, and carries on with the morning commute. A few minutes later, they open the app to finish a task. A small tooltip appears beside the feature they need, explains the benefit in one sentence, and offers a clear next step. This time, they tap.
That contrast captures what is in-app messaging. It's communication delivered inside a product while someone is actively using it, tied to their behaviour, screen, and current task. It isn't another broadcast channel. It's a conversation layer built into the interface.
For NZ and AU founders, that distinction matters. Push notifications, email, and SMS compete for attention outside the product. In-app messages meet users where the work is happening. Used well, they guide onboarding, explain changes, reduce confusion, collect feedback, and help customers solve problems before they contact support. Used badly, they become digital confetti.
I've shipped in-app messaging across three NZ SaaS tools, and the pattern is consistent. The messages that move product metrics feel less like campaigns and more like useful product guidance. The rest look good in a demo, then collect dismissals. Resources such as Vanta Sports messaging tools are useful for seeing how the channel fits into broader product communication, but the work starts with choosing the right moment.
The Auckland user who ignored the feature update wasn't necessarily uninterested. The push arrived at the wrong time, outside the product, with no link to the task in front of them. Inside the app, the same message had a better chance because the user had already raised their hand by opening the product.
That's the core difference. A push notification says, “Come back and look at this.” An email explains a feature in a separate reading environment. An SMS interrupts a personal channel. An in-app message appears beside the control, page, or workflow where the user can act.
Practical rule: If the user can't complete the suggested action from the current screen, the message probably needs a better trigger or a better destination.
In-app messaging can take the form of a tooltip, banner, modal, inline card, slide-out panel, or contextual help prompt. The format matters, but timing and relevance matter more. A tooltip beside an unused report filter can teach discovery. A banner can flag planned maintenance. A support panel can answer a question while the customer is still looking at the account screen.
Messaging already sits comfortably inside everyday digital life in New Zealand. The Commerce Commission's telecom satisfaction tracking found that 74% of respondents had used a messaging app via a device in the last month, with Facebook Messenger and WhatsApp identified as the most popular messaging apps in the market (Commerce Commission messaging app survey).
That doesn't mean every product should copy Messenger. It does mean Kiwi users understand short, timely prompts and conversational interfaces. The product team's job is to make those prompts useful rather than noisy.
The rest is a practical trade-off. Which format earns attention without stealing it? Which trigger reduces support work instead of creating another queue? And when does a simple custom system make more sense than another monthly SaaS bill?
The format sets the interruption cost. Start with the user's task, then choose the lightest presentation that can carry the message.
A modal sits in the centre of the screen, sometimes covering most of the interface. It has high visibility, which makes it suitable for a pricing change, a required onboarding step, a service warning, or a major product announcement.
The downside is blunt. A modal blocks the workflow. If the information isn't urgent, users learn to close it without reading. I reserve modals for messages where missing the information creates a real problem.
A Wellington-based HR tool might use a modal to confirm a new leave-policy workflow that every administrator must review. It shouldn't use one to announce a minor dashboard colour change.
A tooltip anchors to a button, field, or feature. It's a strong choice for progressive onboarding because it explains the control at the point of use, without forcing the user through a long tour.
For example, a Wellington HR platform could show a tooltip beside the employee-import button after a trial user creates their first team. The copy might explain what the import does and point to a sample file. The user can keep working, and the product teaches one useful step at a time.
Tooltips work poorly when they appear before the user has any reason to care. Trigger them after a related action, not just because someone logged in.
A banner sits at the top or bottom of the interface. It suits non-urgent but relevant information, such as a maintenance window, a new feature available to a plan tier, or a reminder about an incomplete setup task.
Banners have lower interruption cost than modals, especially when users can dismiss them. They also have a weakness: people can start treating them as furniture. Keep the copy short, give the banner one clear action, and remove it when its job is done.
A slide-out opens a side panel after a user clicks a help icon, prompt, or feedback control. It gives the team more space than a tooltip without moving the user to a separate support centre.
This format fits support prompts, feedback collection, setup assistance, and carefully timed upgrade offers. A billing platform might open a panel when an administrator reaches a plan limit, showing what the limit affects and offering a route to resolve it.
The trade-off is attention versus depth:
The best choice is rarely the loudest one. It's the format that helps the user finish the task with the least friction.
New Zealand users already understand the basic interaction: a short prompt appears inside a digital product, explains what matters, and offers a next action. They encounter that pattern in banking, shopping, business administration, and customer support. For NZ and Australian SaaS teams, this familiarity makes in-app messaging useful as an operational tool, not only a marketing channel. A well-timed message can answer a setup question before it becomes a ticket or explain a product change without forcing users into a help centre.
A 2026 New Zealand survey reported by Scoop found that Messenger was used at least once daily by 47% of New Zealanders, while WhatsApp was used daily by 25% and Snapchat by 12% (Scoop's New Zealand messaging research). Earlier New Zealand market research also described mobile messaging as the most common activity performed on a smartphone. The practical signal is clear: users are comfortable with brief messages, immediate context, and a defined action.
Messenger also has a broad local audience. A 2025 New Zealand estimate reported 3,259,100 Messenger users, equal to 62.3% of the population. Women represented 52.9% of users, while the 25 to 34 age group was the largest segment, with 811,700 users (New Zealand Messenger audience data).
That familiarity gives product teams a useful starting point. Users can recognise a compact prompt and a visible state change without needing an explanation of the format. The product still has to earn attention, however. A message that interrupts an active workflow, repeats information, or sends users to an irrelevant page creates support work instead of reducing it.
| Metric | NZ/AU data point | Implication for SaaS founders |
|---|---|---|
| Recent messaging use | 74% of NZ survey respondents used a messaging app via a device in the last month (Commerce Commission survey) | In-app conversation patterns are familiar, not exotic |
| Daily Messenger use | 47% of New Zealanders in the 2026 survey | Short, timely prompts fit habitual behaviour |
| Messenger audience | 3,259,100 users, 62.3% of the population | The audience spans a meaningful share of local users |
Acceptance of messaging does not equal patience for interruptions. NZ customers generally expect direct communication and quick resolution. A long paragraph beside a busy workflow feels like paperwork with rounded corners, while a precise prompt can prevent a basic question from reaching support.
The standard is practical: state what changed, explain why it matters, and provide one clear action. Kiwibank's customer messaging work illustrates the value of meeting people in a familiar digital channel while keeping the interaction focused on a useful task. SaaS teams can apply the same principle inside their products. The message should reduce uncertainty or support effort, not merely make a feature announcement visible.
In-app messaging earns its place when it changes product operations, not just campaign engagement. For NZ and AU SaaS teams, that usually means helping users reach value sooner, preventing avoidable confusion, or reducing the support queue.
A new user rarely needs a tour of every menu. They need help reaching the first point where the product solves the problem that brought them there.
A phased tooltip sequence can follow meaningful actions such as creating a workspace, importing data, or inviting a colleague. Each prompt should answer one question and point to one action. A checklist can provide the wider setup view, while the tooltip handles the immediate step.
A practical setup looks like this:
The aim is a clearer path through setup. Extra interface elements are not the goal. If the first screen feels empty or directionless, a focused prompt can stop a trial user from stalling and later asking support what to do next.
Onboarding guidance becomes an operational tool when it answers the same question support receives repeatedly. A Dunedin healthtech startup used a phased tooltip sequence to explain patient setup in stages, rather than placing every instruction on the first screen. The approach reduced patient onboarding calls by 22%.
The lesson is broader than healthcare. If users contact support after reaching a predictable product state, place the explanation beside that state. Measure the change in support demand alongside activation. A higher tooltip click-through rate looks positive, but fewer repetitive calls and more completed setup show whether the message solved a real problem.
Plan upgrades and interrupted checkout flows need careful handling. A slide-out shown when someone reaches a plan limit or leaves a checkout flow can explain the restriction, preserve their work, or offer a relevant route forward.
State the reason for the interruption. If the user has reached a genuine limit, say so. If a feature belongs to a higher plan, explain what it does and who benefits. A useful message reduces uncertainty. A pushy one makes the product feel like a shop assistant following someone around the aisle.
Measure the completed action, not only the click. A user may open the panel, understand the offer, and decide not to upgrade because it is not relevant. That is not automatically failure. A clean dismissal can be healthier than a forced conversion.
Track outcomes that connect messaging to SaaS operations:
| Outcome measure | What to compare | Why it matters |
|---|---|---|
| Activation rate | Users who receive guidance versus comparable users who do not | Shows whether the message helps users reach a meaningful first result |
| Support ticket volume | Repeated setup or feature questions before and after the message | Shows whether guidance removes avoidable support work |
| Plan upgrade conversion | Eligible users who complete an upgrade after reaching a relevant limit | Shows whether the prompt supports informed commercial action |
The strongest message is often easy to miss. It appears beside the problem, gives the user a clear next action, and leaves the support team with fewer predictable questions.
A single message for every user is easy to launch and hard to defend. New users, experienced administrators, inactive accounts, and power users don't need the same nudge. Broadcasting one announcement across all of them is a fast route to fatigue.
Start with three useful cuts:
The segmentation doesn't need to be elaborate on day one. It needs to be meaningful. “Everyone who logged in this month” is usually less useful than “administrators who opened payroll settings but haven't completed the setup”.
Use event-based triggers when the message follows an action, such as creating a project or importing contacts. Use time-based triggers for a meaningful lapse, such as returning after an unfinished setup. Use state-based triggers when the interface reveals a problem, such as an empty dashboard or a failed payment state.
Prioritise those triggers in that order when you can. User-initiated context usually beats an arbitrary delay. A prompt shown beside an empty report has a reason to exist. A prompt shown on the third day because the campaign calendar says so may not.
Personalisation also goes beyond adding a first name. Reflect the user's plan tier, actual usage pattern, role, or team size. A small team shouldn't receive the same setup path as a large account administrator.
For teams building the underlying event and customer logic, CRM and automation development in New Zealand provides a useful reference point for connecting product behaviour with operational workflows.
Test copy, format, and timing as separate variables where possible. Track the intended action, but also watch dismissals, repeat exposure, and support contacts that follow the message.
A high click rate can hide a poor experience if users click only to make an interruption disappear. Dismissal behaviour is a health signal. So is the absence of confusion afterwards.
A message isn't successful because users noticed it. It's successful because the right users took a useful next step.
In-app messages don't sit outside privacy scrutiny. If a message uses a name, device identifier, usage history, support record, or behavioural signal, the organisation needs to treat that information properly under New Zealand's privacy rules.
The Privacy Act 2020 requires organisations to collect only what they need for a lawful business purpose, explain why they're collecting it, and keep it secure (Office of the Privacy Commissioner privacy principles). A message triggered by opens, clicks, dismissals, or feature usage may rely on interaction data collected for a purpose users don't expect. The privacy notice should make that practice understandable.
The Office of the Privacy Commissioner also says people should know what happens to their information, who holds it, and what happens if they don't provide it (Consumer Protection guidance on the Privacy Act). That disclosure belongs near the relevant collection point, not buried where nobody looks.
New Zealand's Privacy Amendment Act 2025 brought Part 2 into force on 24 September 2025, while Part 1 comes into force on 1 May 2026 (New Zealand legislation). The Privacy Commissioner's 2026 report says the new information-collection principle requires reasonable steps to ensure a person is aware that collection is happening, unless an exception applies.
For an app, that makes notice design a product concern. If behavioural data feeds a message trigger, the collection notice should be visible enough that a reasonable person would see it. Profiling logic also deserves plain-language explanation, especially where it decides which users receive different prompts.
A practical review should cover:
Third-party platforms can introduce cross-border questions, particularly for fintech and health SaaS. A message that reduces support load isn't a win if the data flow is unclear.
For a broader view of privacy obligations and data handling in the local market, see this guide to GDPR and New Zealand privacy requirements.
In-app messaging makes sense when a specific user problem is visible and repeated. It doesn't make sense as a decorative layer added because competitors have a product-tour widget.
Assess three things first. Is the core product stable enough that guidance won't explain a moving target? Can the team identify users, events, and product states? And does someone own the message after launch, including replies, stale copy, and unexpected behaviour?
A lightweight custom tooltip system can be enough for one onboarding flow with a few stable events. It may suit a young product that needs precise control and has engineering capacity available.
A platform such as Intercom, Appcues, or Braze becomes more defensible when the team needs richer segmentation, visual campaign management, support integration, surveys, or several message types across multiple journeys. The monthly cost is only one part of the trade-off. Vendor lock-in, data handling, implementation work, and message governance matter too.
Use a simple readiness check:
| Area | Ready signal | Warning signal |
|---|---|---|
| Product | A stable workflow has a clear friction point | The core flow changes every week |
| Data | Events and user states are captured reliably | The team relies on guesswork |
| Ownership | Someone reviews copy and outcomes | Messages launch without an owner |
| Measurement | A baseline exists before launch | Success means “people saw it” |
Pick one high-impact use case. It might be onboarding completion, feature adoption, or support deflection. Write one flow, define its trigger, set a frequency limit, and measure the outcome before adding more.
Teams with existing analytics can often reach a first live message in two weeks. Teams building the foundational data layer first should allow six to eight weeks for the initial setup. Those are planning estimates, not promises, and the difference comes from event quality, approvals, privacy review, and integration work.
Start with one useful interruption. Expand only after the first flow proves its place.
For teams weighing a wider product build, this overview of mobile app development in New Zealand can help frame the engineering choice alongside the messaging work.
NZ Apps helps founders and product teams across New Zealand and Australia make practical decisions about apps, SaaS, automation, and local technology partners. Visit NZ Apps to explore regional resources and connect your in-app messaging plans with the wider product ecosystem.
Add your NZ or Australian app or tech company to the NZ Apps directory and get discovered by founders and operators across the region.
Get ListedReach tech decision-makers across New Zealand and Australia. Sponsored and dofollow editorial links, permanent featured listings, and sponsored articles on a DA30+ .co.nz domain.
See Options