A welcome email is the first email a person receives after subscribing, creating an account, starting a trial, making a purchase, or otherwise giving a business permission to contact them. Its job is to confirm the relationship, deliver the promised next step, set expectations for future messages, and give the recipient an immediate reason to engage.

What is a welcome email?

A welcome email is an onboarding message sent immediately or soon after a user takes a qualifying action. That action might be subscribing to a newsletter, registering for a product, verifying an email address, downloading a resource, joining a loyalty program, or buying for the first time.

The phrase can describe a single message or the first message in a welcome series. A single email is often enough for a simple newsletter subscription. A product with setup steps, a trial period, multiple user roles, or a longer sales cycle may need a sequence that introduces the product gradually over several days.

The important distinction is timing and context. A welcome email is not simply an email with the word “welcome” in its subject line. It is a message triggered by a fresh relationship or a meaningful new lifecycle event. The recipient should be able to understand why they received it without having to search their memory.

For example, these are all valid welcome-email moments:

  • A newsletter reader submits a signup form and receives a subscription confirmation plus an introduction to the publication.
  • A new customer creates an account and receives instructions for verifying their address and completing setup.
  • A SaaS user starts a free trial and receives one focused action to reach an early success milestone.
  • An ecommerce customer makes a first purchase and receives a brand introduction, support details, and relevant post-purchase information.
  • A community member joins a program and receives the rules, benefits, and a way to manage communication preferences.

A welcome email should feel like a continuation of the page, product flow, or transaction that preceded it. If the signup page promised a weekly technical newsletter, the first email should say that clearly. If the user signed up for an app, the message should help them use the app rather than immediately switching to a generic promotional pitch.

Why welcome emails matter for email deliverability

Welcome emails influence deliverability because they are usually sent when recipient intent is at its highest. Someone who has just requested access, subscribed, or completed a purchase is more likely to recognize the sender, open the message, click a useful link, reply to a question, or add the sender to contacts. Those positive interactions cannot guarantee inbox placement, but they create a healthier starting point than mailing an old, ambiguous, or poorly sourced list.

Mailbox providers evaluate many signals when deciding whether mail belongs in the inbox, spam folder, or neither. Authentication, sending reputation, complaint behavior, message format, recipient engagement, and consistency all matter. A welcome email touches several of those factors at once because it establishes who is sending, what will be sent later, and how the recipient can control it.

It connects intent to recognition

A common reason people report legitimate email as spam is that they do not recognize it. That gap often begins at signup. A person may subscribe through a form branded with one product name, then receive an email from a different display name, unfamiliar domain, or parent company.

A strong welcome email closes that gap with plain language:

You’re receiving this because you signed up for Product Updates at example.com.

That sentence is not decorative copy. It is a recognition cue. It reminds recipients of their action and reduces the chance that the email feels unexpected.

The sender name, From address, website domain, signup promise, and email design should all align. If the website uses example.com, sending welcome emails from a related authenticated domain such as mail.example.com can make sense. Sending from a totally different consumer mailbox or unrelated domain creates confusion even when the message is technically legitimate.

It establishes a reputation pattern early

A sender’s reputation is not built by one message alone. It develops from cumulative sending patterns and recipient feedback. Still, the first message matters because it can create the initial pattern for a new stream, domain, or audience segment.

For instance, a new product may send a welcome email immediately after account creation, then send a product-tip email two days later, then a trial reminder five days later. If people consistently engage with those messages, the sender learns which recipients are active and which are not. If recipients ignore, unsubscribe from, or complain about the sequence, that is a signal to reduce pressure and reassess the relevance of the content.

This is especially important when a team is building a new email program. A welcome flow is a controlled way to start: it is event-triggered, targeted to recent signups, and easier to inspect than a large one-time campaign. Instead of sending 100,000 people the same generic promotion, the sender can learn from the behavior of people who have just opted in.

It prevents expectation drift

Expectation drift happens when the frequency, topics, or commercial intensity of later emails do not match what the recipient thought they were signing up for. A welcome email is the right place to prevent that problem.

State the practical details:

  • What type of email will arrive next.
  • How often it will normally arrive.
  • Whether messages include product news, education, promotions, account notices, or all of the above.
  • How the recipient can change preferences or unsubscribe.

A sender does not need to promise an exact schedule it cannot keep. “A few times per month” is better than “every Tuesday” if the actual cadence varies. The point is to provide a realistic expectation that gives the recipient control and reduces surprise.

Welcome email vs. confirmation email vs. transactional email

These terms overlap, but they are not interchangeable.

A confirmation email proves or acknowledges a specific action. Examples include an email-address verification message, a password-reset request, an order confirmation, or a double-opt-in confirmation. Its primary purpose is functional: verify, confirm, or secure something.

A transactional email is triggered by an individual event or relationship and delivers information needed to complete or understand that event. Receipts, shipping notices, password resets, security alerts, and account notifications are common examples. They are usually expected and should be highly reliable.

A welcome email introduces a new relationship. It may be transactional, promotional, or mixed in purpose depending on the situation. For example, a new-account message that verifies an address and explains how to begin using the product has a strong transactional purpose. A newsletter welcome message that offers a discount and introduces a content calendar is more marketing-oriented.

The classification matters because it affects consent expectations, unsubscribe design, sending streams, and content choices. A password-reset email should not be delayed behind a marketing campaign queue. An order receipt should not be used as a vehicle for unrelated advertising. A newsletter welcome email, on the other hand, should make it easy to stop future marketing messages.

Keep critical account actions separate

If a message contains a required account-verification link, password-reset link, or security action, keep the primary purpose unmistakable. Do not bury the action under a long brand story, several promotional blocks, or a dozen competing calls to action.

A practical approach is to send two messages when the contexts are truly different:

  1. Send a short verification or account-confirmation message with one essential action.
  2. Send a separate welcome email after verification or after the person has completed the key account step.

That structure makes the critical email easier to scan and gives the welcome email room to educate, introduce value, and establish preferences.

A welcome email can be part of a transactional lifecycle

For software products, a welcome email often follows a transactional event but aims to create product adoption. A new user has created an account, yet the actual business goal may be getting them to invite a teammate, import data, create a project, or use a core feature.

That means the best welcome email is rarely a broad tour of everything the product can do. It should identify the earliest meaningful outcome and help the recipient reach it. For an analytics product, that could be installing a tracking snippet. For an invoicing tool, it could be creating the first invoice. For an email platform, it might be authenticating a domain and sending a test message using the email API reference and setup guides.

What makes a welcome email effective?

An effective welcome email has a narrow job: help the recipient take the next sensible step while reinforcing why the message arrived. It should reduce uncertainty, not create it.

The exact content depends on the business model, but most good welcome messages include a few durable elements.

1. A recognizable sender identity

Use a stable display name and an address from a domain recipients can connect to your product or organization. Avoid changing the From name on every campaign, particularly at the start of a relationship.

For example, Acme Updates <news@updates.acme.com> is more recognizable than a vague sender such as Team <hello@random-mail-domain.example>. The first example tells a recipient both the brand and the purpose of the stream.

The display name should also make sense in an inbox with no surrounding context. “Maya from Acme” may work for a founder-led product if recipients know Maya. “Acme Product Updates” is clearer if the message is an automated lifecycle email.

2. A subject line that confirms, rather than disguises

The best subject lines typically confirm the recipient’s action or point to the promised value. They do not need to be clever.

Examples:

  • Welcome to Acme Weekly
  • Confirm your Acme account
  • Your Acme trial starts now
  • Here’s your onboarding checklist
  • Thanks for joining — start with your first project

Avoid subject lines that create artificial urgency when there is no deadline. “You need to see this” or “Important update inside” may increase confusion, especially immediately after a signup. A welcome email should build trust, not test how aggressively the sender can chase opens.

3. One primary call to action

A recipient who just subscribed may need only to read the message and understand what comes next. A new user of a product may need one action that unlocks value. The primary call to action should match that context.

Good primary actions include:

  • Verify your email address.
  • Complete your profile.
  • Create your first project.
  • Download the promised guide.
  • Set communication preferences.
  • Browse the most useful getting-started resource.

Secondary links are fine when they support the main task. They should not compete with it. A button to “Create your first campaign” plus links to documentation and support is coherent. A button to start setup, links to six unrelated blog posts, a discount banner, a referral promotion, and a webinar invitation is not.

4. A clear statement of future expectations

Tell subscribers what happens after the first message. This can be a single sentence near the middle or footer:

Expect practical product tips about twice a month. You can update preferences or unsubscribe anytime.

For an onboarding series, explain the sequence in terms of value rather than internal campaign mechanics:

Over the next week, we’ll send three short guides to help you complete setup and get your first result.

That transparency lets recipients decide whether the communication is useful before frustration turns into a complaint.

5. A visible way to leave or adjust preferences

A welcome email is an ideal place to offer preference controls. A newsletter subscriber may want a monthly digest rather than weekly updates. A product user may want technical notices but not promotional announcements. A customer may want order information but not promotional offers.

A preference center is helpful when it gives real choices. It is not helpful when it forces a login, hides the full opt-out option, or turns a straightforward decision into a maze. For commercial mail, recipients should be able to find a clear path to stop future marketing email.

How to measure welcome email performance

A welcome email is not a rate or a metric. It is a message type. However, it should be measured because its timing makes it a high-signal part of an email program.

The right metrics depend on its purpose. A newsletter welcome email may prioritize confirmed subscriptions and first-click behavior. A product welcome email may prioritize activation. An ecommerce welcome email may prioritize first purchase, repeat purchase, or preference completion.

Do not judge the message by opens alone. Open tracking depends on image loading and privacy features, so it is an imperfect proxy for attention. Use it as a directional signal, not as definitive proof that someone read or valued the message.

Core delivery and engagement metrics

Track these metrics at minimum:

  • Delivery rate: the share of accepted sends that did not hard bounce. This helps identify address quality and technical sending problems.
  • Hard bounce rate: the share of messages that permanently failed, often because the address does not exist or cannot receive mail.
  • Soft bounce rate: the share of messages that temporarily failed, which may happen because of a full mailbox, temporary receiver issue, or rate limiting.
  • Spam complaint rate: the share of recipients who report the message as spam, calculated according to the data source being used.
  • Unsubscribe rate: the share of recipients who choose to stop marketing email after receiving the message.
  • Click-through rate: clicks divided by delivered messages, useful when the email has a clear next action.
  • Click-to-open rate: unique clicks divided by unique opens, useful as a directional indicator of whether the email’s content and CTA motivated readers who opened it.
  • Activation rate: the percentage of recipients who complete the intended product action after the email.
  • Time to activation: how long it takes a new recipient to reach the key outcome after signup.

Worked numeric example: activation from a welcome email

Suppose a SaaS company sends a welcome email to 8,000 newly verified trial users. Of those messages, 7,920 are delivered, 2,376 unique recipients open the message, 634 unique recipients click the “Create your first project” button, and 285 create a project within 24 hours.

The basic calculations are:

Delivery rate = delivered / sent × 100
Delivery rate = 7,920 / 8,000 × 100 = 99%

Click-through rate = unique clicks / delivered × 100
Click-through rate = 634 / 7,920 × 100 = 8.0%

Activation rate from delivered welcome emails = activated users / delivered × 100
Activation rate = 285 / 7,920 × 100 = 3.6%

Activation rate from clickers = activated users / unique clicks × 100
Activation rate = 285 / 634 × 100 = 45.0%

The 45.0% click-to-activation figure suggests the landing experience may be reasonably aligned with the email for people who click. The larger question is what happened to the other delivered recipients: did they not open, not understand the value, not need the feature yet, or encounter friction before clicking? That is where segmented analysis matters.

For example, compare activation by signup source, device, plan type, country, role, or the page where the user registered. A welcome email can perform well overall while failing for one high-value segment because the message assumes a use case that segment does not have.

Measure by cohort, not just aggregate averages

A welcome email is triggered continuously, so its results are best studied in cohorts. Compare users who signed up this week with users who signed up last week, rather than blending months of data into one average.

Cohort analysis helps identify real changes. If performance declines after a new form is launched, the issue may be lead quality or a broken consent flow. If clicks decline after a redesigned email, the issue may be copy, rendering, or a less visible CTA. If bounces rise only among one acquisition source, address collection or validation may be the underlying problem.

Common welcome email problems and their causes

When welcome emails underperform, the cause is often upstream of the email template. A beautiful email cannot repair a confusing signup form, a mismatched promise, weak authentication, or an invalid address.

The recipient never receives the email

A missing welcome email can result from several different failures:

  • The recipient entered an invalid or mistyped address.
  • The form accepted disposable, malformed, or nonexistent addresses.
  • The message hard bounced.
  • The trigger was never fired because of an application or integration error.
  • The sending domain lacks correct authentication or has a reputation problem.
  • The recipient’s mail server deferred, filtered, throttled, or blocked the message.
  • The email landed in spam, a promotions category, or a secondary inbox view rather than the primary inbox.

Start by separating application events from delivery events. Did the user actually submit the form? Did the application create the contact? Did the email provider accept the send request? Did the receiving server accept the message? Did the user receive it in any folder?

Those are different questions. Treating every complaint as “an email deliverability problem” leads to slow debugging because the failure may be in the product event pipeline rather than SMTP delivery.

The welcome email is delayed

A welcome email loses relevance quickly. A user who asks for a guide at 10:00 a.m. and receives it two days later may have moved on or forgotten the request. A verification link that arrives after the account-creation session ends may cause support tickets and abandonment.

Delay can come from queue backlogs, provider throttling, retry logic, webhook failures, an automation schedule, or an accidental batch setting. It can also happen when a marketing tool is configured to send at an “optimal time,” which may be inappropriate for an immediate onboarding event.

For time-sensitive welcome messages, send immediately after the event whenever possible. Reserve send-time optimization for later, noncritical lifecycle or campaign mail.

The email gets complaints or unsubscribes

An unsubscribe after a welcome email is not always bad. It may simply mean the recipient no longer wants the content, and a quick unsubscribe is preferable to a spam complaint or months of ignored mail.

A complaint is more serious because it suggests a breakdown in recognition, relevance, or trust. Common causes include:

  • The recipient did not knowingly sign up.
  • The sender identity does not match the signup experience.
  • The email contains more promotion than the user expected.
  • The user was subscribed to several lists without clear consent.
  • The email is sent from a brand they do not recognize after a co-marketing or lead-generation flow.
  • The unsubscribe path is hard to find or difficult to complete.

The solution is not to hide the unsubscribe link. It is to fix the expectation gap. Review the signup language, consent capture, source attribution, sender identity, and first-message content. If you cannot explain in one plain sentence why each recipient is receiving the email, the program is likely too ambiguous.

The message has high opens but low clicks

High opens and low clicks can mean the subject line is stronger than the body, but it can also mean the email did its job without requiring a click. A newsletter welcome message may only need to set expectations. A product welcome email that needs activation, however, should make the next step unmistakable.

Review the message hierarchy. Is the CTA visible without scrolling on a mobile screen? Does the button label state the outcome? Does the surrounding copy explain why the user should click now? Does the destination page preserve the same context?

A button labeled “Get started” is generic. “Create your first project” is more specific. “Verify email and finish setup” tells the recipient both the action and the outcome.

The message is delivered but cannot be read or used

Rendering and accessibility problems can quietly damage onboarding. An image-only email may be nearly blank when images are blocked. Tiny type, low color contrast, vague link labels, or a layout that breaks on mobile can prevent recipients from completing the intended step.

Build welcome emails as functional messages first. Use live text for the main explanation and CTA. Include meaningful alt text for informative images. Keep the design responsive. Make links easy to tap. Test the message across common mailbox providers and devices before treating a template as final.

How to improve welcome email deliverability

Improving welcome-email deliverability means improving both the technical foundation and the recipient experience. These layers reinforce each other: perfect authentication cannot make unwanted mail wanted, and excellent copy cannot overcome a broken sending setup.

Authenticate the sending domain

Use the email authentication methods expected by major mailbox providers: SPF, DKIM, and DMARC. The precise DNS records and configuration values depend on the sending provider and domain architecture, so use provider-specific documentation rather than copying records from another system.

Authentication helps receivers verify that the sender is authorized to use the domain and makes spoofing harder. It also helps align the visible From domain with authenticated identifiers used by receiving systems.

Google’s sender guidance requires baseline authentication for senders to personal Gmail accounts and imposes additional requirements on bulk senders. Yahoo likewise emphasizes authentication, valid sending infrastructure, low complaint rates, and easy unsubscribe mechanisms. These standards should be treated as operational requirements, not optional deliverability polish.

Send from a stable, recognizable domain

Do not rotate domains merely to avoid reputation consequences. Constantly changing domains can weaken recognition and look like evasive behavior. Instead, use a stable domain strategy and separate message streams only where it creates a clear operational benefit.

For example, a company might use one authenticated subdomain for product and account mail and another for marketing mail. The key is not the exact naming convention; it is that the identities are legitimate, consistently used, authenticated, and understandable to recipients.

Validate addresses before and at signup

Address quality is a foundational deliverability issue. If a form collects typo-filled, temporary, fake, or nonexistent addresses, the welcome stream will produce unnecessary bounces and failed onboarding.

Use several layers of defense:

  1. Validate basic syntax in the form without blocking reasonable valid addresses.
  2. Require email verification when the account or content access justifies it.
  3. Check address quality before importing or sending to acquired lists.
  4. Suppress hard-bounced addresses immediately.
  5. Investigate sudden bounce increases by signup source or form version.

For pre-send list hygiene, an email address verification tool can help identify addresses that should not enter a campaign or re-engagement audience. It should complement, not replace, clear consent and a verification flow for high-value accounts.

Make unsubscribing easy for marketing mail

For marketing and subscription messages, include a visible unsubscribe link in the email body. Large-volume senders should also support the relevant list-unsubscribe standards expected by mailbox providers.

RFC 8058 defines a header-based one-click unsubscribe pattern. A basic illustrative header pair looks like this:

List-Unsubscribe: <https://email.example.com/unsubscribe/recipient-token>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The HTTPS endpoint should accept the prescribed POST-based unsubscribe request, and the headers must be properly DKIM-signed for RFC 8058 use. The token should be opaque and recipient-specific; do not place an easily guessable email address or account identifier in a public URL.

One-click unsubscribe does not replace the body unsubscribe link. Recipients should still have a clear, visible choice inside the message itself. The destination should process the request directly or present a simple preference choice without making the recipient hunt, log in, complete a survey, or prove who they are.

For U.S. commercial email, the FTC states that senders must provide a clear opt-out mechanism and honor opt-out requests within 10 business days. Mailbox-provider guidelines can be stricter operationally; Google and Yahoo guidance for applicable bulk mail emphasizes honoring unsubscribes within two days.

Keep the first send focused and honest

A welcome email should not act like a quarterly promotional blast. Keep the content close to the recipient’s action. If they requested a download, give them the download. If they created an account, help them start. If they joined a newsletter, explain what they will receive.

Avoid stuffing the message with every possible announcement. The more unrelated material included, the harder it is for a recipient to understand the purpose of the email and the more likely they are to disengage.

Control frequency after the welcome message

The first message sets a baseline. The follow-up schedule determines whether that baseline becomes a useful relationship or an annoyance.

Build a welcome series around milestones rather than arbitrary pressure. If the user has already completed setup, do not continue sending beginner reminders. If they have not opened several onboarding messages, consider pausing, reducing frequency, changing the content angle, or offering a preference option rather than escalating urgency.

A simple event-driven sequence could look like this:

  • Immediately after signup: confirm the relationship and deliver the promised action or resource.
  • One day later, if the key action is incomplete: send one short setup guide focused on the biggest blocker.
  • Three days later, if still incomplete: show a concrete example of the desired outcome.
  • After completion: stop the setup nudges and transition the user into an appropriate customer or subscriber lifecycle.

Building a welcome email workflow for developers

For developers, the most reliable welcome-email program begins with explicit events and idempotent handling. “Send welcome email” should not be a vague side effect scattered across the codebase. It should be a defined lifecycle event with clear eligibility rules.

A typical flow may include these steps:

  1. A user submits a signup form or completes an account-creation action.
  2. The application normalizes and stores the email address.
  3. The application determines whether verification is required before marketing or onboarding content is sent.
  4. A domain event, such as user.registered or subscriber.confirmed, is recorded.
  5. A worker sends the correct template for the user’s state and locale.
  6. The sending system records the provider message identifier and internal event identifier.
  7. Delivery, bounce, complaint, unsubscribe, and click events update the user’s communication state.
  8. Subsequent workflow steps check that state before sending another message.

Idempotency matters. If a background job retries after a timeout, it should not send the same welcome email three times. Store an immutable event ID or a dedicated “welcome email sent at” value, then make the send operation safe to retry.

Keep lifecycle state separate from analytics state. “Sent welcome email” and “opened welcome email” are different facts. A recipient may receive an email without loading tracking pixels. They may click an email link from a privacy-protected client without producing a conventional open event. Product events such as verified account, created project, or completed purchase are usually stronger indicators of success.

Use a suppression-aware sending path

Every welcome-email send should check suppression state. Do not send marketing mail to an address that previously unsubscribed, hard bounced, or complained. If a recipient must receive essential account or security information, handle that stream under its own carefully defined rules rather than casually overriding marketing suppression.

Also make unsubscribe processing durable. When the unsubscribe endpoint receives a request, write the suppression state promptly, keep an audit record, and ensure downstream systems receive the update. A preference center, CRM, marketing platform, and sending API that disagree about whether a person is subscribed will eventually create a complaint or compliance problem.

Monitor provider events and application events together

Email delivery data answers only part of the question. A delivered welcome email does not mean a new user successfully activated. Likewise, a user might activate after reading an email without clicking a tracked link.

Combine provider events with product analytics:

  • Send accepted by provider.
  • Delivery succeeded or bounced.
  • Recipient clicked a setup link.
  • User verified an account.
  • User completed the intended activation event.
  • User unsubscribed or complained.

This combined view reveals where the journey breaks. If delivery is high but activation is low, focus on message clarity, landing-page friction, and product setup. If delivery is low, investigate addresses, authentication, and reputation before redesigning the CTA.

Welcome email checklist

Before launching or revising a welcome email, use this practical checklist:

  • Does the email arrive immediately after a recognizable user action?
  • Can a recipient understand why they received it in the first screen of the email?
  • Does the sender name and From domain match the brand and signup experience?
  • Is the main call to action singular, specific, and useful?
  • Is the message readable with images disabled and on a small screen?
  • Is the sending domain authenticated with the required standards?
  • Are hard bounces, complaints, and unsubscribes automatically suppressed from future marketing sends?
  • Does the message include a clear body unsubscribe link when it is marketing or subscription mail?
  • Are list-unsubscribe headers configured where required for the sending stream?
  • Is the workflow idempotent so retries cannot generate duplicate welcomes?
  • Are delivery events connected to activation and product events?
  • Have the signup promise, message content, and later email cadence been reviewed together?

The long-term value of a better welcome email

A welcome email is often treated as a small automation: write a friendly note, add a button, and move on. That approach misses its role as the first operational test of an email program.

It tests whether consent is clear, whether the address is valid, whether authentication is working, whether sending infrastructure is reliable, whether product events fire correctly, whether the recipient recognizes the sender, and whether the next step is worth taking.

Because the recipient is newly engaged, the welcome email is also one of the best places to learn. It can show whether the signup page attracted the right audience, whether onboarding language is understandable, and whether the product’s first-value moment is easy enough to explain in one message.

The strongest welcome emails are not necessarily the most elaborate. They are timely, expected, technically sound, clear about the next action, and respectful of the recipient’s control over future messages. Get those fundamentals right, then use data from delivery, engagement, and activation to improve the sequence over time.

FAQ

Is a welcome email transactional or marketing email?

It can be either, or contain elements of both. A welcome email that verifies an account or provides essential setup information has a transactional purpose. A newsletter or promotional welcome message is marketing-oriented. Keep critical account actions separate from unrelated promotions whenever possible.

When should a welcome email be sent?

Send it immediately after the qualifying event in most cases. Account verification, requested resources, and onboarding instructions lose value when delayed. Later follow-up messages can be spaced around user behavior and milestones.

Should a welcome email include an unsubscribe link?

Yes, when it is a marketing or subscription message. Include a clear body unsubscribe link and, where applicable, list-unsubscribe headers that support one-click unsubscribe. Essential security or account messages may follow different rules, but should still be narrowly focused on their functional purpose.

What is a good welcome email call to action?

A good CTA asks for the single most useful next step. Examples include “Verify your email,” “Create your first project,” “Download the guide,” or “Set your preferences.” Make the action specific and align it with what the recipient just signed up to do.

Why did my welcome email go to spam?

Possible causes include weak or missing authentication, poor domain or IP reputation, a confusing sender identity, a low-quality signup source, high complaint history, invalid addresses, or content that does not match recipient expectations. Check application send logs, provider delivery events, authentication, complaint data, and the signup journey before changing copy alone.