WhatsApp Business Marketing for Italian ecommerce: automated campaigns via Spoki

WhatsApp Business has become, in Italy, one of the channels with the best cost-to-conversion ratio for ecommerce, especially in segments where the audience has low email familiarity or where cash-on-delivery (COD) payment is still significant. Among the Italian platforms integrating the WhatsApp Business API, Spoki has carved out a meaningful position thanks to its combination of approved templates, campaign management and real-time webhooks. When the integration is done well, a WhatsApp campaign produces results that are hard to obtain on other channels; when it is done badly, it burns templates, irritates customers and, in the worst case, gets the business number suspended.

In this article I describe the architecture I built for a pet care brand with a catalog of around twelve hundred SKUs, a customer base of sixty thousand contacts reachable via WhatsApp, and a meaningful share of COD orders. The goal was to have a WhatsApp campaign platform integrated with the ecommerce CRM, with automatic throttling to avoid saturating the daily template quota and with an order confirmation flow capable of reducing COD return rates.

The problem: WhatsApp is not email

The first mistake when setting up a WhatsApp strategy is to treat it like email. WhatsApp has different operational constraints: templates must be pre-approved by Meta, every send outside the conversation window has a per-message cost, hourly quotas exist on the number’s tier, and an abnormal share of “reported as spam” can lead to a downgrade of the numbering rating, up to a block. This means the technical architecture must manage approval status, throttling, audience filtering, and — above all — must prevent the marketing team from launching campaigns with a single click that could burn the number asset.

Architecture: three layers working together

The architecture that works is built on three layers: template management, audience materialization, controlled sending.

The template layer is the source of truth on approved WhatsApp templates. Spoki exposes the API to read status, language and variables of templates. By syncing this information locally, the campaign creation UI can prevent wrong choices (e.g. selecting a template in “Pending” status or with missing variables). It sounds obvious, but it is the number one source of operational errors in the marketing team.

The audience layer is where integration with the ecommerce CRM lives. The difference between a mediocre and an effective campaign is the segment. For the brand in question we defined fifteen dynamic segments based on purchase behavior (e.g. “bought wet food in the last sixty days”, “has a COD order pending delivery”, “abandoned cart above forty euros”). When marketing launches a campaign, the system materializes the audience at that precise moment, saving the snapshot of contacts and any parameters (e.g. pet name, suggested product). This materialization is fundamental because it prevents a segment change during the send from skewing results, and because it makes the campaign repeatable and auditable.

The sender layer is the worker that performs the send. This is where the most important technical piece sits: intelligent throttling. Spoki enforces a per-minute/hour send limit based on the number’s tier. Exceeding this limit generates 429 errors and — worse — negatively impacts reputation. The worker I built dynamically computes the send rate based on three variables: current tier of the number, percentage of template already used in the last twenty-four hours, and recipient timezone (do not send at three in the morning). If the campaign is large — say thirty thousand recipients — the worker distributes it intelligently over six to eight hours, maintaining sustainable throughput and delivery windows at reasonable times.

The order confirmation flow: the COD case

The use case that produces the clearest ROI on WhatsApp is not the promotional campaign, it is order confirmation, especially in markets with high COD weight. The mechanics are simple but the operational detail makes the difference.

When a COD order comes in, Shopify emits a webhook. The integration captures the event, tags the order as COD, and — if the customer has WhatsApp consent and a verified number — sends a confirmation template with order summary, shipping address, amount and a call-to-action to confirm or modify. The customer replies inside the conversation, and this reply opens the twenty-four hour window in which free-form messages can be sent without template cost.

The effect on COD returns is significant. On a monthly volume of about eighteen hundred COD orders, the introduction of the WhatsApp confirmation flow led to a measurable reduction in packages refused at delivery, because the address is verified before shipment and the customer is “warmed up” for the imminent delivery. The savings in logistics costs and return handling cover the template cost many times over.

Conversation backfill and contact sync: the boring but essential parts

A WhatsApp ecommerce platform needs two less glamorous but critical functions: bidirectional contact sync between CRM and Spoki, and conversation backfill by phone number when customer service opens a customer card. Without these two, the CS agent who receives a call from a WhatsApp customer has no idea what was said in the latest conversations and treats the customer as new.

Contact sync must be idempotent and handle conflicts: the phone number in Spoki is the natural key, but the source of truth on master data (name, language, marketing consent) is the ecommerce CRM. Conversation backfill, on the other hand, is on-demand querying: when the agent opens the customer card, the system fetches message history for that number from the Spoki API and presents it chronologically.

Tech stack and design choices

The stack I used: Supabase Edge Functions in Deno for the backend, React/Lovable for the campaign and template management UI, Spoki API for the WhatsApp Business integration, a dedicated background worker for the throttled sender, Shopify webhooks for triggering order confirmations. The Postgres database hosts campaign state, materialized audience, synthetic conversation history and throttling metadata.

The decision to put the sender on a dedicated worker rather than on an Edge Function was driven by the pattern: the sender must maintain rate state (how many templates sent in the last 60 minutes, how many in the last 24h) and this out-of-request state is awkward to manage in an Edge Function. A worker that loops with backpressure is much simpler and more reliable.

Take-aways

Three things to remember if you are evaluating WhatsApp Business automation in an Italian ecommerce. First: throttling is not an option, it is a requirement. A campaign that burns your number tier is worth much less than the damage it does. Build the sender with dynamic throttling from day one. Second: the main source of value is not the outbound campaign, it is the transactional flow (order confirmation, shipment, post-purchase follow-up). Start there, that is where ROI shows up immediately and where engagement rates justify the investment. Third: treat templates as versioned assets. Maintain a staging set of templates, do reviews before submitting them to Meta for approval, and keep a log of which campaign used which version. Without this, six months down the line no one will know why a certain template is performing differently than before.