TL;DR: Most HubSpot and WhatsApp setups only handle the outbound half. Replies land somewhere nobody is watching. Sync inbound messages to the contact, route them to the contact’s owner, and send anything that sounds like a question or a doubt to a human.

Your CRM is probably not the reason your leads are dying.

Teams blame lead quality, then the ads, then the sales team. Almost nobody blames the setup in the middle, and that is where the damage happens.

Here is the plot twist. You already connected HubSpot to WhatsApp. Messages are going out. And leads still go cold, because connecting two tools is not the same as building a follow up system. One moves data. The other keeps a person interested.

The failure nobody tests for

A lead fills a form. HubSpot logs it. A WhatsApp template fires. Everyone feels good.

Then the lead replies with a question, and nothing happens. The reply sits in a chat window nobody is watching, or it shows up in HubSpot as a line of text with no alert.

The lead did not lose interest. They got a door that only opened one way. We test the send path carefully and treat the reply as an afterthought, but on WhatsApp the reply is the whole point.

So start from a different question. Not “what message should we send?” but “who answers when the lead replies?” If you cannot name a person, a time window and a backup, the integration is not ready.

Step 1: Catch inbound messages properly

Your WhatsApp provider will send inbound messages to a webhook. Verify the signature, acknowledge fast, and do the real work after. Here is a minimal Node example using the Cloud API style payload:

js import express from "express"; import crypto from "crypto";

const app = express(); app.use(express.json({ verify: (req, _res, buf) => { req.rawBody = buf; } }));

function validSignature(req) { const sig = req.get("x-hub-signature-256") || ""; const expected = "sha256=" + crypto.createHmac("sha256", process.env.APP_SECRET) .update(req.rawBody) .digest("hex"); return ( sig.length === expected.length && crypto.timingSafeEqual(Buffer.from(sig), Buffer.from(expected)) ); }

app.post("/webhooks/whatsapp", async (req, res) => { if (!validSignature(req)) return res.sendStatus(401); res.sendStatus(200); // reply quickly, process afterwards

const msg = req.body.entry?.[0]?.changes?.[0]?.value?.messages?.[0]; if (!msg || msg.type !== "text") return;

const phone = "+" + msg.from; const text = msg.text.body;

const contact = await findContact(phone); if (!contact) return; // decide how you want to handle unknown numbers

await logNote(contact.id, text); if (needsHuman(text)) await createTask(contact, text); });

Two small things save a lot of pain later. Store phone numbers in full international format in HubSpot, and clean duplicate contacts before you go live. A missing country code breaks the thread before it starts.

Step 2: Sync replies back to the contact

Many setups log what you sent but not what the lead said. Your rep opens the contact and sees a one sided conversation. Match the inbound number to a contact, then write the reply to the timeline:

js const HS = "https://api.hubapi.com"; const headers = { Authorization: Bearer ${process.env.HUBSPOT_TOKEN}, "Content-Type": "application/json", };

async function findContact(phone) { const r = await fetch(${HS}/crm/v3/objects/contacts/search, { method: "POST", headers, body: JSON.stringify({ filterGroups: [{ filters: [{ propertyName: "phone", operator: "EQ", value: phone }] }], properties: ["firstname", "hubspot_owner_id"], }), }); const data = await r.json(); return data.results?.[0]; }

async function logNote(contactId, text) { await fetch(${HS}/crm/v3/objects/notes, { method: "POST", headers, body: JSON.stringify({ properties: { hs_timestamp: new Date().toISOString(), hs_note_body: WhatsApp reply from lead: ${text}, }, associations: [ { to: { id: contactId }, types: [{ associationCategory: "HUBSPOT_DEFINED", associationTypeId: 202 }], }, ], }), }); }

Now every inbound message shows up on the contact timeline, and the story is no longer half missing.

Step 3: Route by ownership, not luck

If a lead already spoke to Priya last week, Priya should get the reply. Random assignment makes people repeat themselves, which is a quiet way to lose them. The contact’s owner is already in HubSpot, so use it:

js async function createTask(contact, text) { await fetch(${HS}/crm/v3/objects/tasks, { method: "POST", headers, body: JSON.stringify({ properties: { hs_timestamp: new Date().toISOString(), hs_task_subject: "Reply to WhatsApp message", hs_task_body: text, hs_task_status: "NOT_STARTED", hubspot_owner_id: contact.properties.hubspot_owner_id, }, associations: [ { to: { id: contact.id }, types: [{ associationCategory: "HUBSPOT_DEFINED", associationTypeId: 204 }], }, ], }), }); }

The owner now gets a task the moment a lead writes back. Nobody has to assume somebody else is watching the chat.

Step 4: One rule for where automation ends

I am pro automation. I am also firmly against automating the moment a lead is deciding. Automation is great for confirmations, reminders and quick answers. It is poor at reading hesitation. Someone who writes “let me think about it” is not asking for another template. They want a person to say something real.

Here is a simple starting rule: a question mark or a doubt goes to a human, and a date, a name or a yes can stay with the system.

js function needsHuman(text) { return /?|not sure|let me think|maybe|too expensive|price|cost/i.test(text); }

It is crude, and you should tune it with real conversations. But this one rule protects the moments that matter, and it fixes a surprising number of cold lead problems.

Mistakes that quietly kill leads after integration

No owner for inbound replies, so everyone assumes someone else is watching.

A fast automated message followed by a slow human one, which feels worse than a steady pace.

Three templates in a row with no pause, which reads as pressure and not care.

Dirty data: wrong numbers, missing country codes, duplicate contacts. Treating hot leads and browsing leads with the same sequence.

No monthly review, so the setup never improves.

What a good setup feels like to the lead

It does not feel like a system. It feels like a business that pays attention. The lead gets a quick, relevant message, replies, and someone who knows what they asked answers. Nothing repeats and nothing feels random.

That is the real goal. Not more messages, but less friction between a lead’s question and a person’s answer.

If you would rather not build and maintain all of this yourself, a shared inbox that sits on top of the WhatsApp Business API gives your team one place where every reply is visible. That is what we build at Emovur.

TL;DR: Meta caps how many unique people you can message per day outside an open chat. Sort your list into four waves by engagement, send the warmest contacts first, keep 20% of the cap free for order updates, and check results before every batch.

Every developer knows the feeling. You build the feature, load the data, hit run, and the API replies with a rate limit.

Now picture the same thing with a marketing list. A business uploads 10,000 contacts, expects one big send, and finds out the platform will only let it reach 250 people tomorrow. So what gets sent first? In most cases, whatever row happens to sit at the top of the CSV, which is usually the oldest, coldest contact on the list.

If you treat the limit like a rate limit and the list like a queue, you can fix this in an afternoon.

The Constraint Nobody Reads Until It Bites

On the WhatsApp Business API, Meta caps how many different people you can message in 24 hours outside an open chat. New accounts start at 250 and can grow from there.

Two details matter if you are designing around it.

The limit is per business portfolio, not per number. Every number in the portfolio shares one pool, so adding a second number does not add capacity.

The limit also grows because of how you send, not because time passes. Meta looks at message quality before it lets your cap increase, so waiting around for a bigger limit gets you nothing. Start now with your best contacts and let your sending history build.

The Math: How Long Does a Big List Take? List size At 250 a day At 2,000 a day At 10,000 a day 5,000 contacts 20 days 3 days 1 day 10,000 contacts 40 days 5 days 1 day 20,000 contacts 80 days 10 days 2 days

These numbers assume you spend the whole cap on one campaign. You shouldn’t, and that is the next section.

Reserve Capacity Like You Would in Any System

Campaigns are not the only traffic that uses your daily number. Order updates, payment reminders and appointment alerts sent outside an open chat can draw from the same cap.

Think of it as reserved capacity for critical traffic. Keep a buffer of around 20% so your transactional messages always go out. Practically, that means a cap of 250 gives you about 200 campaign messages a day, so a 10,000 contact list takes closer to 50 days than 40.

Sort the Queue Before You Batch It

The default order of a CSV is file order, and file order has no idea who is engaged. Sort your contacts into four waves first.

Wave 1: customers who bought or replied in the last 30 to 60 days Wave 2: older customers Wave 3: leads who enquired but never bought Wave 4: old or imported contacts you know the least about

Engaged people reply. Cold contacts ignore or block. A strong first wave protects your quality signals, and that helps every wave after it.

One rule applies to the whole queue: if you can’t say why someone is on your list, leave them out. Start with a permission based broadcast list.

A Small Planner You Can Adapt

Here is a simple Python sketch of the idea. It is a generic example for planning your batches, not an Emovur API call. It dedupes numbers, sorts by wave and recency, and cuts the queue into daily batches that respect your buffer.

python import math from datetime import date, timedelta

CAMPAIGN_SHARE = 0.8 # keep about 20% of the cap free

def plan_batches(contacts, daily_limit, start=None): start = start or date.today() usable = int(daily_limit * CAMPAIGN_SHARE)

# send each number once only
seen, unique = set(), []
for c in contacts:
    if c["phone"] not in seen:
        seen.add(c["phone"])
        unique.append(c)

# warmest first: wave, then most recent engagement
queue = sorted(unique, key=lambda c: (c["wave"], c["days_since_engaged"]))

batches = []
for day, i in enumerate(range(0, len(queue), usable)):
    batches.append({
        "send_date": start + timedelta(days=day),
        "contacts": queue[i:i + usable],
    })
return batches

how many days will this take?

math.ceil(len(contacts) / (daily_limit * CAMPAIGN_SHARE))

Write each batch out as one CSV per day, and you have your sending plan.

Running a Daily Batch in Emovur

This is where the plan meets the tool. In Emovur’s WhatsApp broadcast tool, one daily batch looks like this:

Prepare the batch. One CSV per day, or one segment per wave. Create a broadcast. Pick your approved message template. Add recipients. Upload the CSV or select the segment. Use Enter Numbers for a quick test. Set up the message. Add text, media, dynamic variables or a dynamic URL, and map each variable to a column. Handle duplicates. If a number appears twice, choose to send once only. Set retries and schedule. Send at the same time each day. Check results before the next batch. Look at delivery and replies. If people are blocking or ignoring you, fix the message before the next wave.

That last step is your feedback loop. Treat each wave like a deploy: ship it, watch the metrics, then decide whether the next one goes out.

Bugs That Quietly Break Bulk Campaigns

Sending in file order. Your oldest contacts go first. Sort by engagement before you batch.

Spending the full cap on a campaign. Nothing is left for order updates. Keep the buffer.

Hitting Wave 1 again every day. The same people get tired and blocks rise. Track who got which batch.

Duplicate numbers in one CSV. One person gets two messages. Choose send once only.

Changing everything between batches. You can’t tell what worked. Change one variable at a time, like you would in any experiment.

Edge Cases Worth Planning For

What if an offer expires before the last wave? Match the offer to the waves you can reach in time. Send a time limited offer to the first waves only, and give later waves a different message that still makes sense.

How do you know a wave worked? Check delivery, replies and blocks the next morning. If replies are low or blocks are rising, pause and fix the message before you send more.

Should cold contacts be included at all? Only if they agreed to hear from you. If they did, put them in the last wave and test with a small batch first. If they did not, leave them out and collect fresh permission instead.

Ship the Plan, Not Just the List

Having 10,000 contacts does not mean you can message 10,000 people tomorrow. The limit sets how many you can reach each day, and your plan decides who those people are. Send in waves, start with the contacts most likely to reply, keep a buffer for order updates, and check each wave before the next one goes out.

Emovur’s broadcast tool handles the work around it. You can upload a CSV, pick a segment or enter numbers, map your template variables, send once to repeated numbers, and schedule each wave for the same time every day.

Before you plan your first wave, see what running it will cost. Check Emovur’s pricing and see how it fits the size of your list.