SMS Messaging Program

ZeroACE is a US software company providing AI order-management and customer-messaging software to online retailers. Messages under this program are order-related and transactional, and are sent on behalf of the merchant whose store the customer ordered from.

Every message begins with that merchant's store name, so the recipient always knows which store the message is about:

Messages are one-to-one and are triggered by the recipient's own order activity. The program covers:

• Order confirmation
• Payment links for an order the customer is placing
• Shipping confirmation and tracking updates
• Delivery updates
• Return, exchange and refund status
• Replies to the customer's own order-related questions

Message frequency varies and is driven by the recipient's own order: a message is sent when something happens to it. Most orders produce between one and five messages — a confirmation, a shipping notice, a delivery notice, and a reply if the customer asks something. An order with a return or an exchange produces a few more. No messages are sent when there is no order activity.

No promotional or marketing messages are sent on this program. Marketing SMS is not a capability of the software: our consent model has no SMS marketing channel, so no customer can opt in to one and no such message can be generated.

Consent has two parts, because the number reaches us at two different moments. The first message is implied by the transaction: the customer is already on a call or in a chat with the business, gives a number so the business can tell them about the order they are placing, and the notice below is shown or spoken at that moment. Messages after that one are sent later, to a number typed into a form, so the form carries an agreement the customer ticks themselves.

That agreement is never pre-selected and is never a condition of ordering. Leaving it unticked does not block the order; it means the business reaches the customer by email about the delivery instead, which is why an email address is asked for whenever the box is left clear.

A number reaches us by one of four routes. The first three are screens and scripts in our own software; the fourth is the merchant's own checkout.

1. Our delivery-details form. One form, shown on two surfaces: as a web page we host, opened from a link we text the customer during a phone call, and as a card inside the chat assistant when the customer is ordering by chat. Identical fields, identical notice under the phone field — the two are held in step by an automated check that fails our build if their wording diverges.
2. Spoken on a voice call, when no form can be delivered to that caller and the details are taken in conversation.
3. Caller ID on an inbound phone call: the number is already attached to the call, so the assistant does not ask for it. The spoken notice below is the disclosure for this route.
4. The merchant's own checkout, for stores whose own hosted checkout collects the customer's details itself (Shopify is the common case). On that route the merchant collects the number on their own checkout page, under their own disclosure, and ZeroACE sends the order messages for them. Which stores these are is not a matter of which platform they run: it is whether that platform's checkout collects the details, and each integration declares that for itself. WooCommerce, for one, does not — its order total is fixed before the customer sees the payment page, so the delivery address has to be known first, and a WooCommerce customer therefore gives their number on the form described in route 1, under the notice quoted below.

Reproduced here word for word. The store's name is substituted where it appears; when the store's name is unavailable the notice reads "The store".

Directly below that notice, on the same form, is the agreement itself — a single checkbox, cleared by default:

The notice names what the messages are, how often they come, that they may carry a cost, and how to stop them. The HELP keyword is set out on this page, which the notice links to as "SMS terms", so it is one tap from the field rather than a fifth sentence above it.

On a voice call there is no screen, so the assistant says it. It is instructed to state this once, when confirming the order, and to present it as a notice rather than a request — it does not ask for permission and does not wait for an answer:

The form that collects a phone number is created for one order and consumed when it is submitted, so no link to it can stay working long enough to be reviewed: opening an old one shows an expiry notice rather than the form. The screenshots below are therefore the record of what a customer actually sees, taken from the live pages.

The chat-assistant surface is the same form rendered as a card inside the conversation, and it is not screenshotted separately because it is not a second consent mechanism: the notice, the field it sits under and the three links are the same text. The two surfaces are kept identical by an automated check that compares them against the wording quoted on this page and fails our build if any of the three drifts apart.

Sent bodies, quoted from the message templates. The store name and the order reference are variables. Every message names the sending platform and carries the opt-out instruction.

Links in these messages point to our own domains. We do not use public URL shorteners.

Replying STOP stops the messages. The following keywords are honoured: STOP, STOPALL, UNSUBSCRIBE, CANCEL, END, QUIT, OPTOUT, REVOKE. Replying START resubscribes.

Replying HELP (or INFO) returns this, word for word:

An opt-out is recorded against the number and enforced before a message is handed to any carrier, not only at the carrier's own filter. Because these are order notifications rather than marketing, a customer who stops them will not be told about their own delivery — so the assistant never presents opting out as a routine choice, and never as a condition of ordering.

Stated plainly because it is the one route we do not control. Where a store's own hosted checkout is what collects the customer's contact details, the customer enters their phone number on that platform's page, not on any page of ours, and the disclosure they see there is the merchant's.

The test is what that checkout COLLECTS, not where the order is completed — the two come apart, and getting them the wrong way round would describe this route as covering traffic it does not. A WooCommerce order is completed on the merchant's own site, yet its total is fixed before the customer reaches the payment page, so the delivery address must be known in advance and is taken on our form instead. Every integration declares which details its checkout collects, and that declaration is what decides whether a customer is ever shown our form at all.

What ZeroACE does on that route is send the order messages described above, prefixed with that merchant's store name, and honour STOP and HELP for them exactly as on every other route.

Our Privacy Policy has a section on text messaging: mobile numbers and SMS opt-in information are not sold, rented or shared with any third parties or affiliates for their own marketing purposes.

Our Terms of Service have a matching section covering message frequency, that message and data rates may apply, STOP and HELP, and that carriers are not liable for delayed or undelivered messages.

Privacy Policy: https://zeroace.ai/privacy — Terms of Service: https://zeroace.ai/terms