Delivery, Bounces & Unsubscribes

What This Page Covers

How FSRevs tracks message delivery and handles problems — including email bounces, spam complaints, customer unsubscribes, and SMS delivery failures. Understanding these helps you maintain healthy sending practices and know why certain customers may stop receiving requests.

This delivery tracking applies to messages sent through FSRevs. When you send from your own device, FSRevs records that it prepared the message but cannot see delivery events from your phone’s email or messaging app.

Email Delivery Lifecycle

When you send a review request or form request via email, FSRevs tracks its progress through these stages:

Status	Meaning
Sent	The message was handed off to the email provider
Delivered	The recipient’s email server accepted the message
Opened	The email provider reported an open event; this does not prove the customer read or acted on the email
Bounced	The email could not be delivered (see below)
Unsubscribed	The recipient opted out of future emails
Complaint	The recipient marked the email as spam

These are recorded events, not a guaranteed sequence. A message can be delivered without a recorded open. Delivered means the recipient’s server accepted it; it does not identify an inbox folder or confirm a completed response.

Open the request’s Message History to inspect the actual message and events. When both email and SMS were used, check each message separately; one channel can succeed while the other fails.

Email Bounces

A bounce happens when an email can’t be delivered to the recipient’s inbox.

Hard Bounces (Permanent)

The email address is invalid or permanently unreachable. Common causes:

The email address doesn’t exist
The domain doesn’t exist
The recipient’s server permanently rejected the message

Soft Bounces

A temporary delivery failure — the address exists but the message couldn’t be delivered right now. Common causes:

The recipient’s mailbox is full
The recipient’s server is temporarily unavailable

A soft-bounce event does not itself add the address to FSRevs’ hard-bounce suppression list. Check the message details and current contact status before retrying; do not assume a fixed number of retries or an automatic resend.

Spam Complaints

If a recipient marks your email as spam, FSRevs records a complaint for that message. The email address is immediately added to the suppression list with the highest priority — complaint suppressions cannot be automatically overridden by any other status.

When FSRevs can identify the customer and account, a complaint also revokes that customer’s existing email and SMS marketing permission. Historical permission remains visible, but fresh affirmative permission is required before the customer can become eligible again.

To help prevent future complaints, follow Deliverability, Consent & Inbox Placement: ask first, set clear expectations, and send through a channel the customer has agreed to use.

Customer Unsubscribes

Customer request emails sent through FSRevs include an unsubscribe link. When a customer uses it to unsubscribe:

The email address is added to the suppression list
The message is marked as unsubscribed
All future email sends to that address are blocked
When the customer can be identified, earlier email and SMS marketing permission for that customer is revoked within the account

Clearing an Unsubscribe

The existing unsubscribe page can clear an actual unsubscribe when that action is available. It cannot clear a spam complaint or hard-bounce restriction.

Clearing the unsubscribe does not restore an earlier marketing grant. The customer must affirmatively grant fresh permission through a configured Review Flow, Custom Form, or a controlled staff action.

Why Old Permission Does Not Return

FSRevs keeps permission history and current restrictions separate. A previous grant remains useful evidence of what happened, but an unsubscribe, STOP request, or complaint creates a newer revocation boundary. Removing the current suppression later does not erase that boundary or make the old grant active again.

SMS Delivery Failures

When sending requests via SMS, delivery issues are tracked similarly:

Failed SMS deliveries are logged with the error details from the carrier
A failed or undelivered SMS can immediately add the number to a phone suppression list; repeated failures are not required
Suppressed phone numbers are blocked from future SMS sends

An SMS STOP request is different from an ordinary delivery failure. STOP immediately suppresses the exact phone number. When FSRevs can identify the customer and account, it also revokes that customer’s existing email and SMS marketing permission. Fresh permission is still required if the restriction is later cleared through a valid process.

Hard bounces, invalid values, and ordinary delivery failures block delivery but do not by themselves mean that the customer withdrew permission. If the contact later becomes deliverable, its permission can be evaluated again unless a later unsubscribe, STOP request, complaint, or explicit revocation also applies.

Viewing Suppressed Contacts

Open a customer and select Contact Methods to see whether an exact email address or phone number is permitted, blocked, revoked, not permitted, or inactive. Use Permission history for the recorded events and current blocking reason.

Marketing permission and deliverability are different checks. A valid marketing grant does not override a hard bounce or STOP restriction, and a deliverable address does not itself establish marketing permission.

Resolve a Delivery Problem

Find the request in Flow Activity or Form Responses and open Message History.
Confirm the sending method. Prepared for direct sending has no provider delivery tracking.
Review the email and SMS messages separately, including any failure reason.
Confirm the exact contact value with the customer and review Contact Methods for restrictions.
If the request is pending, wait for a result before creating another request. If it failed, resolve the cause and confirm the customer still expects it before retrying.

Do not clear a complaint, unsubscribe, or STOP restriction just to make a request send. If the reason remains unclear, contact support with the request, channel, time, and status.

Best Practices

Verify contact information before sending — typos in email addresses cause unnecessary bounces
Send to recent customers — older email addresses are more likely to bounce
Don’t send to disengaged contacts — repeated sends to unresponsive contacts increase complaint risk
Monitor your activity — check the Flow Activity section regularly for delivery issues