whatblast
Test a WhatsApp campaign from audience selection to the final customer action. Verify eligibility, variables, links, media, timing and reply handling with authorised test contacts. When delivery fails, inspect the available status and fix the cause before retrying. Do not treat repeated sending as troubleshooting.
A preview window can look perfect while the real journey is broken. The greeting may use the wrong field, the destination may require a login or the campaign may be scheduled in another time zone. Testing is the process of discovering those problems before customers do. It should be practical, repeatable and proportionate to the campaign.
Define what a successful test looks like
Write down the expected behaviour before sending a test. The message should reach the authorised recipient, display the correct content, open the intended destination and support the promised action. If replies are part of the journey, someone should receive and handle them through the expected process.
Separate visual checks from functional checks. A correctly styled button is not proof that its link works. A delivered message is not proof that the recipient can complete a booking. Review the whole path rather than stopping at the first green status indicator.
Keep a small test record with the campaign version, test contacts, device context, expected result and actual result. This helps the team reproduce a problem and avoids repeating the same investigation from memory. It also makes it clear which version was approved.
Check the audience before the message
Compare the final audience count with the intended segment and exclusions. Look for duplicates, stale records and contacts who already completed the action. Make sure preference changes have been applied to the latest export rather than an earlier draft.
Review a sample of records manually. Confirm that the reason for contact described in the message is true for those people. If the text says they requested a restock update, the segment should be based on that request. A technically successful send to the wrong audience is still a failed campaign.
Use internal or otherwise authorised recipients for testing. Do not send experimental variations to random numbers. Keep personal data out of public logs, screenshots and project repositories. The test record should contain enough information to investigate without becoming an unnecessary copy of the customer database.
Exercise dynamic fields
Test a normal record, a missing-name record and a record with long or unusual characters. Include the languages you actually support. Check dates, product names, locations and any other inserted values. A single successful “Hello Alex” does not prove every variable will behave correctly.
Look for extra spaces, awkward punctuation and fallback text that sounds unnatural. If a name is absent, the sentence should still read smoothly. If a required booking detail is absent, the record should be reviewed rather than sent with a vague substitute.
Confirm that the preview and actual received message agree. Some problems appear only during the final substitution or delivery step. Save a screenshot of the received test when useful, taking care not to expose private contact information.
Open every link on a phone
Tap each link from the actual test message. Check that it opens the expected page, uses the correct domain and does not lead through an unnecessary or broken redirect. Verify that tracking parameters remain intact where needed without exposing personal details.
Test the destination as a customer would encounter it. A page that works while you are logged into an administrator account may fail for an ordinary visitor. Check product availability, booking options, forms and any important information needed to make the decision.
Stop before making a real purchase or performing another unintended transaction. You can inspect the path to checkout and use an authorised test environment where one exists. Do not create live payments simply to prove that a campaign link is clickable.
Inspect media after delivery
Look at the received image or video on more than one relevant device if possible. Check cropping, legibility, loading and whether the main subject remains clear. The exported file can be handled differently by the receiving interface, so inspecting only the design source is not enough.
Play video with sound off and confirm that essential information remains understandable. Review captions and the opening frame. If the campaign depends on a specific product detail, make sure compression has not obscured it.
Keep important conditions in readable text as well. A media failure should not turn the message into a mystery. The media-design guide explains how to build assets that remain useful at phone-preview size.
Verify timing and reply ownership
Confirm the selected time zone and scheduled date in the final saved campaign. Check whether a recent edit changed the schedule or required another confirmation. If the message expires after a deadline, make sure a delayed send will not publish stale information.
Send a test reply and follow it through the team’s process. Identify who sees it, how they connect it to the campaign and when they escalate a question. A campaign that invites replies to an unmonitored channel creates avoidable frustration.
Test the after-hours case if it matters. The customer should receive an accurate expectation about when the team can help, and the request should remain visible for the next working period. Do not promise immediate assistance unless that coverage exists.
Troubleshoot delivery by evidence
When a message does not arrive, begin with the status information available in the sending setup. Record the time, campaign identifier and any error category. Distinguish a rejected request, a pending event and a recorded delivery failure. These states may require different actions.
| Symptom | First check | Avoid |
|---|---|---|
| Import rejected | Column mapping, encoding and required fields | Repeatedly uploading the same broken file |
| Variable missing | Field names and fallback rules | Sending the full audience before correction |
| Media rejected | Supported format and current file limits | Changing random settings without a record |
| Link fails | Destination availability and access requirements | Assuming the customer is using it incorrectly |
| Delivery problem | Available status, recipient data and account setup | Uncontrolled retries or bypass attempts |
Do not interpret every failure as a blocked recipient or a platform restriction. The evidence may be incomplete. Use the provider’s support process when the cause is unclear, and share only the information necessary to investigate.
Pause safely when something is wrong
Define pause conditions before launching. Examples include a broken destination, incorrect personalisation, unavailable stock or a pattern of unexpected errors. Identify who can stop unsent messages and how they will communicate the decision to the team.
After pausing, establish the scope: what was sent, what remains queued and which recipients were affected. Avoid immediately creating another campaign as a workaround. You could duplicate messages or make the original problem harder to diagnose.
Fix the cause and repeat the relevant test. If a correction is necessary, make it clear and limited to the affected audience. A calm, accurate recovery is more useful than a series of rushed explanations sent to everyone.
Retry only when the reason supports it
A retry should follow a defined rule. Confirm whether the original message could still arrive and whether the system prevents duplicate delivery. If the status is ambiguous, investigate before sending again. A customer receiving the same message three times is unlikely to admire your determination.
Respect account restrictions and platform requirements. Do not rotate numbers, evade controls or repeatedly contact people who asked to stop. A legitimate delivery issue should be handled through data correction, configuration review or the provider’s support process.
Record the retry decision and result. This helps distinguish an isolated issue from a recurring workflow problem. If the same failure returns, fix the process rather than making retries a permanent part of normal operation.
Keep a compact release checklist
- Audience and current exclusions reviewed.
- Dynamic fields and fallback cases tested.
- Message and media inspected after delivery.
- Every destination checked on mobile.
- Dates, prices and availability confirmed.
- Schedule and time zone verified.
- Reply owner and backup ready.
- Pause and recovery process understood.
- Approved version saved with test evidence.
Use the checklist consistently, but adapt it to the campaign. A complex booking workflow needs more cases than a simple informational update. The aim is to catch meaningful failures, not to create a ceremony that everyone learns to tick without thinking.
After launch, review the first available results and any unexpected questions. Testing continues as observation, but it should not become uncontrolled experimentation on customers. Feed genuine findings into the next version of the checklist and the campaign brief.
Frequently asked questions
Is one test message enough?
It may confirm a basic path, but it does not cover missing variables, different devices or booking changes. Choose test cases based on the features used by the campaign. A small, deliberate set of edge cases is more useful than repeatedly sending the same perfect example.
Should I resend a message when the status is unclear?
Investigate first. An unclear status may not mean the message failed, and another send can create duplicates. Check the available event information and provider guidance, then retry only when the reason and expected behaviour are understood.
What evidence should I keep?
Keep the campaign version, expected behaviour, relevant status or error category and a concise description of the result. Screenshots can help when they avoid unnecessary personal information. Store the evidence appropriately and do not publish private customer details in development logs.
Can testing guarantee delivery?
No. It can reduce avoidable mistakes and verify the process under tested conditions. Recipient availability, account status and external services can still affect outcomes. Use monitoring and a clear recovery process rather than promising that every message will always arrive.