Use case · Sales · Lead

Reply to a new lead in seconds, before anyone opens the record.

A record-triggered flow on Lead sends the first message the moment the record is created, stamps when it went and on which channel, and leaves the SDR a task instead of a queue to watch.

ObjectLead

Fires onRecord created, after save

Reply landsTask on the Lead, thread on the record

ChannelWhatsApp, SMS where no template applies

01 · What quietly breaks

The delay happens before a human ever sees the record.

Slow speed to lead gets blamed on SDR discipline. Read the timestamps and the first gap is earlier than that: the lead lands at 14:02, the assignment rule fires, and nothing leaves the building until somebody opens the queue at 14:40. By then the buyer has filled in two more forms.

The usual fix is a bigger rota, which costs headcount and still leaves nights, weekends and the hour after a webinar uncovered. All of that expense buys one sentence that never changes.

And because it is typed by hand, the wording changes every time. Nobody can say afterwards what the buyer was actually told, which matters the first time somebody asks.

02 · The idea

The first reply is a template, not a person. Fire it on record creation, stamp when it went, and hand the SDR a task rather than a queue.

03 · The pattern

Three parts, and the flow is the only thing you build.

Two tracking fields on Lead, one template per channel, one record-triggered flow. Everything else is standard Salesforce.

01

Add two fields, so speed to lead is a number

First_Auto_Reply_Sent_At__c and First_Response_Channel__c. Without them there is no before and after, and the rollout stays a matter of opinion. They also give the flow something to check, so a re-saved or merged lead cannot collect a second first reply.

In Salesforce ObjectLeadFieldsFirst_Auto_Reply_Sent_At__c (Date/Time), First_Response_Channel__c (Picklist)PhoneMobilePhone, or a dedicated WhatsApp_Number__cRegionCountry, or a normalised Region__c

02

Write the first reply once

One WhatsApp template and one SMS version, both held in ValueText, both reviewed once. An SDR never types the first message, so what a buyer is told at 23:00 on a Friday is what they are told at 09:00 on a Tuesday.

In Salesforce TemplateLead_First_Reply (WhatsApp, approved)FallbackLead_First_Reply_SMSMerge fieldsLead.FirstNameSegments1

03

Fire it on create, not on assignment

A record-triggered flow on Lead, after save. Entry conditions keep it to real inbound: not converted, a messaging-capable phone present, and LeadSource in the inbound set. That last condition is the one that stops an overnight import texting nine thousand people.

Before it sends, the flow calls the shared guardrail subflow. After it sends, it stamps both fields and creates a follow-up Task owned by the lead owner.

In Salesforce Flow typeRecord-triggered, Lead, created, after saveEntryIsConverted = false AND phone != null AND LeadSource IN (Web Form, Landing Page, Paid Ads, Chatbot)GuardrailSubflow Messaging_Guardrails_Check → CanSend, ReasonCodeThenSend Message, stamp the two fields, create Task

Fig 01 · 00Q5f00000L2xQe · Marta Vidal

Hi Marta, thanks for reaching out. We have your details and someone will follow up shortly. You can reply here if you want to add anything.

Sent 14:02:07 · from Flow · template Lead_First_Reply

Yes. We are looking at about 40 seats and we need it live before the end of the quarter.

Received 14:09 · Task on Lead · First_Response_Channel__c = WhatsApp

Understood, 40 seats and a quarter-end date. Your account manager will call you today.

Sent 14:11 · sent by the SDR from the Converse view

04 · Replies and exceptions

The reply is the handover.

Every inbound message lands as a Task on the Lead and opens the thread in the Converse view, so the SDR picks up a conversation rather than starting one.

ReplyWhat happensWhere it lands

Any reply Task on the Lead, owner set to the lead owner. The thread is already in the Converse view with what was sent and when. Task on Lead

Buying detail Nothing automatic fires. The SDR answers on the same thread, so the whole exchange stays on the record through conversion. Message Bucket on Lead

Wrong number A keyword rule clears the phone field and flags the record, so the next campaign does not send to it again. Lead.MobilePhone, Bad_Number__c

STOP Opt-out set on the Lead. Every later flow skips it, and it carries to the Contact on conversion. Lead.SMS_Opt_Out__c

05 · Guardrails

Four checks, and they are the same four the rest of the org uses.

ConsentThe shared subflow reads ContactPointConsent before any send. A transactional first reply to an inbound enquiry is a different case from marketing, and that distinction belongs in the subflow rather than in this flow.

Quiet hoursRegion comes off the Lead. The subflow blocks anything outside the window for that region and returns a ReasonCode, which the flow logs rather than swallows.

One per leadFirst_Auto_Reply_Sent_At__c is checked before the send, so a re-save, a merge or a reopened record cannot trigger a second one.

Opt-out lineCarried in the WhatsApp template. The SMS version fits it inside the same segment.

06 · Reporting afterwards

Speed to lead stops being an argument and becomes a column.

First_Auto_Reply_Sent_At__c minus CreatedDate is the number the rota discussion was really about. A Lead report grouped by source shows it per channel, before and after the rollout.

Inbound leads · first responseLeads

        SourceLeadsMedian first replyReplied
      

Web form4127s31%

Paid ads2886s24%

Chatbot968s44%

Landing page617s28%

MEDIAN FIRST REPLYFirst_Auto_Reply_Sent_At__c minus CreatedDate. The number it replaces was measured in minutes and depended on the hour of day.

REPLIEDLeads carrying at least one inbound Message Bucket. This is the one that predicts a booked call, not the send count.

BLOCKEDLeads where the guardrail returned CanSend = false, grouped by ReasonCode. A rising consent count is a form problem, not a messaging one.

07 · Implementation note

Where ValueText fits.

ValueText is the send action and the inbound handler. It installs from AppExchange as a managed package, adds the Send Message invocable action to Flow Builder, and writes every inbound message as a Message Bucket record and a Task on the Lead. Templates, keyword rules and the org-level send window live in ValueText Setup. The two fields, the flow, the guardrail subflow and the report are yours, built with standard tools, and they keep working if you change the number or the carrier.

Professional edition or above · WhatsApp needs an approved template for the first message · 1 SMS segment per reply at the published per-country rate

AppExchange review

“Valuetext is the outstanding solution to integrate whatsapp and sms into salesforce. The support team can also only be praised in highest tones…”

Cédric BaumgartnerCPO & Co-Founder · AppExchange

This page sits underWhatsApp for SalesforceThe channel page: templates, the 24 hour window and Meta pricing.

In the docs

01 Sending Messages from Flow in SalesforceThe invocable action, its inputs and the test run → 02 WhatsApp Approved TemplatesSubmitting a template and what the 24 hour window changes → 03 Record Linking for First Incoming MessagesHow an inbound reply finds the Lead it belongs to →

Run your messaging inside your CRM.

Rated 4.98 on Salesforce AppExchange

Talk to us Request a sandbox

ValueText

Use case · Sales · Lead

Reply to a new lead in seconds, before anyone opens the record.

A record-triggered flow on Lead sends the first message the moment the record is created, stamps when it went and on which channel, and leaves the SDR a task instead of a queue to watch.

ObjectLead

Fires onRecord created, after save

Reply landsTask on the Lead, thread on the record

ChannelWhatsApp, SMS where no template applies

01 · What quietly breaks

The delay happens before a human ever sees the record.

Slow speed to lead gets blamed on SDR discipline. Read the timestamps and the first gap is earlier than that: the lead lands at 14:02, the assignment rule fires, and nothing leaves the building until somebody opens the queue at 14:40. By then the buyer has filled in two more forms.

The usual fix is a bigger rota, which costs headcount and still leaves nights, weekends and the hour after a webinar uncovered. All of that expense buys one sentence that never changes.

And because it is typed by hand, the wording changes every time. Nobody can say afterwards what the buyer was actually told, which matters the first time somebody asks.

02 · The idea

The first reply is a template, not a person. Fire it on record creation, stamp when it went, and hand the SDR a task rather than a queue.

03 · The pattern

Three parts, and the flow is the only thing you build.

Two tracking fields on Lead, one template per channel, one record-triggered flow. Everything else is standard Salesforce.

01

Add two fields, so speed to lead is a number

First_Auto_Reply_Sent_At__c and First_Response_Channel__c. Without them there is no before and after, and the rollout stays a matter of opinion. They also give the flow something to check, so a re-saved or merged lead cannot collect a second first reply.

In Salesforce ObjectLeadFieldsFirst_Auto_Reply_Sent_At__c (Date/Time), First_Response_Channel__c (Picklist)PhoneMobilePhone, or a dedicated WhatsApp_Number__cRegionCountry, or a normalised Region__c

02

Write the first reply once

One WhatsApp template and one SMS version, both held in ValueText, both reviewed once. An SDR never types the first message, so what a buyer is told at 23:00 on a Friday is what they are told at 09:00 on a Tuesday.

In Salesforce TemplateLead_First_Reply (WhatsApp, approved)FallbackLead_First_Reply_SMSMerge fieldsLead.FirstNameSegments1

03

Fire it on create, not on assignment

A record-triggered flow on Lead, after save. Entry conditions keep it to real inbound: not converted, a messaging-capable phone present, and LeadSource in the inbound set. That last condition is the one that stops an overnight import texting nine thousand people.

Before it sends, the flow calls the shared guardrail subflow. After it sends, it stamps both fields and creates a follow-up Task owned by the lead owner.

In Salesforce Flow typeRecord-triggered, Lead, created, after saveEntryIsConverted = false AND phone != null AND LeadSource IN (Web Form, Landing Page, Paid Ads, Chatbot)GuardrailSubflow Messaging_Guardrails_Check → CanSend, ReasonCodeThenSend Message, stamp the two fields, create Task

Fig 01 · 00Q5f00000L2xQe · Marta Vidal

Hi Marta, thanks for reaching out. We have your details and someone will follow up shortly. You can reply here if you want to add anything.

Sent 14:02:07 · from Flow · template Lead_First_Reply

Yes. We are looking at about 40 seats and we need it live before the end of the quarter.

Received 14:09 · Task on Lead · First_Response_Channel__c = WhatsApp

Understood, 40 seats and a quarter-end date. Your account manager will call you today.

Sent 14:11 · sent by the SDR from the Converse view

04 · Replies and exceptions

The reply is the handover.

Every inbound message lands as a Task on the Lead and opens the thread in the Converse view, so the SDR picks up a conversation rather than starting one.

ReplyWhat happensWhere it lands

Any reply Task on the Lead, owner set to the lead owner. The thread is already in the Converse view with what was sent and when. Task on Lead

Buying detail Nothing automatic fires. The SDR answers on the same thread, so the whole exchange stays on the record through conversion. Message Bucket on Lead

Wrong number A keyword rule clears the phone field and flags the record, so the next campaign does not send to it again. Lead.MobilePhone, Bad_Number__c

STOP Opt-out set on the Lead. Every later flow skips it, and it carries to the Contact on conversion. Lead.SMS_Opt_Out__c

05 · Guardrails

Four checks, and they are the same four the rest of the org uses.

ConsentThe shared subflow reads ContactPointConsent before any send. A transactional first reply to an inbound enquiry is a different case from marketing, and that distinction belongs in the subflow rather than in this flow.

Quiet hoursRegion comes off the Lead. The subflow blocks anything outside the window for that region and returns a ReasonCode, which the flow logs rather than swallows.

One per leadFirst_Auto_Reply_Sent_At__c is checked before the send, so a re-save, a merge or a reopened record cannot trigger a second one.

Opt-out lineCarried in the WhatsApp template. The SMS version fits it inside the same segment.

06 · Reporting afterwards

Speed to lead stops being an argument and becomes a column.

First_Auto_Reply_Sent_At__c minus CreatedDate is the number the rota discussion was really about. A Lead report grouped by source shows it per channel, before and after the rollout.

Inbound leads · first responseLeads

        SourceLeadsMedian first replyReplied
      

Web form4127s31%

Paid ads2886s24%

Chatbot968s44%

Landing page617s28%

MEDIAN FIRST REPLYFirst_Auto_Reply_Sent_At__c minus CreatedDate. The number it replaces was measured in minutes and depended on the hour of day.

REPLIEDLeads carrying at least one inbound Message Bucket. This is the one that predicts a booked call, not the send count.

BLOCKEDLeads where the guardrail returned CanSend = false, grouped by ReasonCode. A rising consent count is a form problem, not a messaging one.

07 · Implementation note

Where ValueText fits.

ValueText is the send action and the inbound handler. It installs from AppExchange as a managed package, adds the Send Message invocable action to Flow Builder, and writes every inbound message as a Message Bucket record and a Task on the Lead. Templates, keyword rules and the org-level send window live in ValueText Setup. The two fields, the flow, the guardrail subflow and the report are yours, built with standard tools, and they keep working if you change the number or the carrier.

Professional edition or above · WhatsApp needs an approved template for the first message · 1 SMS segment per reply at the published per-country rate

AppExchange review

“Valuetext is the outstanding solution to integrate whatsapp and sms into salesforce. The support team can also only be praised in highest tones…”

Cédric BaumgartnerCPO & Co-Founder · AppExchange

This page sits underWhatsApp for SalesforceThe channel page: templates, the 24 hour window and Meta pricing.

In the docs

01 Sending Messages from Flow in SalesforceThe invocable action, its inputs and the test run → 02 WhatsApp Approved TemplatesSubmitting a template and what the 24 hour window changes → 03 Record Linking for First Incoming MessagesHow an inbound reply finds the Lead it belongs to →

Run your messaging inside your CRM.

Rated 4.98 on Salesforce AppExchange

Talk to us Request a sandbox

ValueText

Log in Start free trial Talk to us→

Use case · Sales · Lead

Reply to a new lead in seconds, before anyone opens the record.

A record-triggered flow on Lead sends the first message the moment the record is created, stamps when it went and on which channel, and leaves the SDR a task instead of a queue to watch.

ObjectLead

Fires onRecord created, after save

Reply landsTask on the Lead, thread on the record

ChannelWhatsApp, SMS where no template applies

01 · What quietly breaks

The delay happens before a human ever sees the record.

Slow speed to lead gets blamed on SDR discipline. Read the timestamps and the first gap is earlier than that: the lead lands at 14:02, the assignment rule fires, and nothing leaves the building until somebody opens the queue at 14:40. By then the buyer has filled in two more forms.

The usual fix is a bigger rota, which costs headcount and still leaves nights, weekends and the hour after a webinar uncovered. All of that expense buys one sentence that never changes.

And because it is typed by hand, the wording changes every time. Nobody can say afterwards what the buyer was actually told, which matters the first time somebody asks.

02 · The idea

The first reply is a template, not a person. Fire it on record creation, stamp when it went, and hand the SDR a task rather than a queue.

03 · The pattern

Three parts, and the flow is the only thing you build.

Two tracking fields on Lead, one template per channel, one record-triggered flow. Everything else is standard Salesforce.

01

Add two fields, so speed to lead is a number

First_Auto_Reply_Sent_At__c and First_Response_Channel__c. Without them there is no before and after, and the rollout stays a matter of opinion. They also give the flow something to check, so a re-saved or merged lead cannot collect a second first reply.

In Salesforce ObjectLeadFieldsFirst_Auto_Reply_Sent_At__c (Date/Time), First_Response_Channel__c (Picklist)PhoneMobilePhone, or a dedicated WhatsApp_Number__cRegionCountry, or a normalised Region__c

02

Write the first reply once

One WhatsApp template and one SMS version, both held in ValueText, both reviewed once. An SDR never types the first message, so what a buyer is told at 23:00 on a Friday is what they are told at 09:00 on a Tuesday.

In Salesforce TemplateLead_First_Reply (WhatsApp, approved)FallbackLead_First_Reply_SMSMerge fieldsLead.FirstNameSegments1

03

Fire it on create, not on assignment

A record-triggered flow on Lead, after save. Entry conditions keep it to real inbound: not converted, a messaging-capable phone present, and LeadSource in the inbound set. That last condition is the one that stops an overnight import texting nine thousand people.

Before it sends, the flow calls the shared guardrail subflow. After it sends, it stamps both fields and creates a follow-up Task owned by the lead owner.

In Salesforce Flow typeRecord-triggered, Lead, created, after saveEntryIsConverted = false AND phone != null AND LeadSource IN (Web Form, Landing Page, Paid Ads, Chatbot)GuardrailSubflow Messaging_Guardrails_Check → CanSend, ReasonCodeThenSend Message, stamp the two fields, create Task

Fig 01 · 00Q5f00000L2xQe · Marta Vidal

Hi Marta, thanks for reaching out. We have your details and someone will follow up shortly. You can reply here if you want to add anything.

Sent 14:02:07 · from Flow · template Lead_First_Reply

Yes. We are looking at about 40 seats and we need it live before the end of the quarter.

Received 14:09 · Task on Lead · First_Response_Channel__c = WhatsApp

Understood, 40 seats and a quarter-end date. Your account manager will call you today.

Sent 14:11 · sent by the SDR from the Converse view

04 · Replies and exceptions

The reply is the handover.

Every inbound message lands as a Task on the Lead and opens the thread in the Converse view, so the SDR picks up a conversation rather than starting one.

ReplyWhat happensWhere it lands

Any reply Task on the Lead, owner set to the lead owner. The thread is already in the Converse view with what was sent and when. Task on Lead

Buying detail Nothing automatic fires. The SDR answers on the same thread, so the whole exchange stays on the record through conversion. Message Bucket on Lead

Wrong number A keyword rule clears the phone field and flags the record, so the next campaign does not send to it again. Lead.MobilePhone, Bad_Number__c

STOP Opt-out set on the Lead. Every later flow skips it, and it carries to the Contact on conversion. Lead.SMS_Opt_Out__c

05 · Guardrails

Four checks, and they are the same four the rest of the org uses.

ConsentThe shared subflow reads ContactPointConsent before any send. A transactional first reply to an inbound enquiry is a different case from marketing, and that distinction belongs in the subflow rather than in this flow.

Quiet hoursRegion comes off the Lead. The subflow blocks anything outside the window for that region and returns a ReasonCode, which the flow logs rather than swallows.

One per leadFirst_Auto_Reply_Sent_At__c is checked before the send, so a re-save, a merge or a reopened record cannot trigger a second one.

Opt-out lineCarried in the WhatsApp template. The SMS version fits it inside the same segment.

06 · Reporting afterwards

Speed to lead stops being an argument and becomes a column.

First_Auto_Reply_Sent_At__c minus CreatedDate is the number the rota discussion was really about. A Lead report grouped by source shows it per channel, before and after the rollout.

Inbound leads · first responseLeads

        SourceLeadsMedian first replyReplied
      

Web form4127s31%

Paid ads2886s24%

Chatbot968s44%

Landing page617s28%

MEDIAN FIRST REPLYFirst_Auto_Reply_Sent_At__c minus CreatedDate. The number it replaces was measured in minutes and depended on the hour of day.

REPLIEDLeads carrying at least one inbound Message Bucket. This is the one that predicts a booked call, not the send count.

BLOCKEDLeads where the guardrail returned CanSend = false, grouped by ReasonCode. A rising consent count is a form problem, not a messaging one.

07 · Implementation note

Where ValueText fits.

ValueText is the send action and the inbound handler. It installs from AppExchange as a managed package, adds the Send Message invocable action to Flow Builder, and writes every inbound message as a Message Bucket record and a Task on the Lead. Templates, keyword rules and the org-level send window live in ValueText Setup. The two fields, the flow, the guardrail subflow and the report are yours, built with standard tools, and they keep working if you change the number or the carrier.

Professional edition or above · WhatsApp needs an approved template for the first message · 1 SMS segment per reply at the published per-country rate

AppExchange review

“Valuetext is the outstanding solution to integrate whatsapp and sms into salesforce. The support team can also only be praised in highest tones…”

Cédric BaumgartnerCPO & Co-Founder · AppExchange

This page sits underWhatsApp for SalesforceThe channel page: templates, the 24 hour window and Meta pricing.

In the docs

01 Sending Messages from Flow in SalesforceThe invocable action, its inputs and the test run → 02 WhatsApp Approved TemplatesSubmitting a template and what the 24 hour window changes → 03 Record Linking for First Incoming MessagesHow an inbound reply finds the Lead it belongs to →

Run your messaging inside your CRM.

Rated 4.98 on Salesforce AppExchange

Talk to us Request a sandbox

ValueText

Log in Start free trial Talk to us→

Use case · Sales · Lead

Reply to a new lead in seconds, before anyone opens the record.

A record-triggered flow on Lead sends the first message the moment the record is created, stamps when it went and on which channel, and leaves the SDR a task instead of a queue to watch.

ObjectLead

Fires onRecord created, after save

Reply landsTask on the Lead, thread on the record

ChannelWhatsApp, SMS where no template applies

01 · What quietly breaks

The delay happens before a human ever sees the record.

Slow speed to lead gets blamed on SDR discipline. Read the timestamps and the first gap is earlier than that: the lead lands at 14:02, the assignment rule fires, and nothing leaves the building until somebody opens the queue at 14:40. By then the buyer has filled in two more forms.

The usual fix is a bigger rota, which costs headcount and still leaves nights, weekends and the hour after a webinar uncovered. All of that expense buys one sentence that never changes.

And because it is typed by hand, the wording changes every time. Nobody can say afterwards what the buyer was actually told, which matters the first time somebody asks.

02 · The idea

The first reply is a template, not a person. Fire it on record creation, stamp when it went, and hand the SDR a task rather than a queue.

03 · The pattern

Three parts, and the flow is the only thing you build.

Two tracking fields on Lead, one template per channel, one record-triggered flow. Everything else is standard Salesforce.

01

Add two fields, so speed to lead is a number

First_Auto_Reply_Sent_At__c and First_Response_Channel__c. Without them there is no before and after, and the rollout stays a matter of opinion. They also give the flow something to check, so a re-saved or merged lead cannot collect a second first reply.

In Salesforce ObjectLeadFieldsFirst_Auto_Reply_Sent_At__c (Date/Time), First_Response_Channel__c (Picklist)PhoneMobilePhone, or a dedicated WhatsApp_Number__cRegionCountry, or a normalised Region__c

02

Write the first reply once

One WhatsApp template and one SMS version, both held in ValueText, both reviewed once. An SDR never types the first message, so what a buyer is told at 23:00 on a Friday is what they are told at 09:00 on a Tuesday.

In Salesforce TemplateLead_First_Reply (WhatsApp, approved)FallbackLead_First_Reply_SMSMerge fieldsLead.FirstNameSegments1

03

Fire it on create, not on assignment

A record-triggered flow on Lead, after save. Entry conditions keep it to real inbound: not converted, a messaging-capable phone present, and LeadSource in the inbound set. That last condition is the one that stops an overnight import texting nine thousand people.

Before it sends, the flow calls the shared guardrail subflow. After it sends, it stamps both fields and creates a follow-up Task owned by the lead owner.

In Salesforce Flow typeRecord-triggered, Lead, created, after saveEntryIsConverted = false AND phone != null AND LeadSource IN (Web Form, Landing Page, Paid Ads, Chatbot)GuardrailSubflow Messaging_Guardrails_Check → CanSend, ReasonCodeThenSend Message, stamp the two fields, create Task

Fig 01 · 00Q5f00000L2xQe · Marta Vidal

Hi Marta, thanks for reaching out. We have your details and someone will follow up shortly. You can reply here if you want to add anything.

Sent 14:02:07 · from Flow · template Lead_First_Reply

Yes. We are looking at about 40 seats and we need it live before the end of the quarter.

Received 14:09 · Task on Lead · First_Response_Channel__c = WhatsApp

Understood, 40 seats and a quarter-end date. Your account manager will call you today.

Sent 14:11 · sent by the SDR from the Converse view

04 · Replies and exceptions

The reply is the handover.

Every inbound message lands as a Task on the Lead and opens the thread in the Converse view, so the SDR picks up a conversation rather than starting one.

ReplyWhat happensWhere it lands

Any reply Task on the Lead, owner set to the lead owner. The thread is already in the Converse view with what was sent and when. Task on Lead

Buying detail Nothing automatic fires. The SDR answers on the same thread, so the whole exchange stays on the record through conversion. Message Bucket on Lead

Wrong number A keyword rule clears the phone field and flags the record, so the next campaign does not send to it again. Lead.MobilePhone, Bad_Number__c

STOP Opt-out set on the Lead. Every later flow skips it, and it carries to the Contact on conversion. Lead.SMS_Opt_Out__c

05 · Guardrails

Four checks, and they are the same four the rest of the org uses.

ConsentThe shared subflow reads ContactPointConsent before any send. A transactional first reply to an inbound enquiry is a different case from marketing, and that distinction belongs in the subflow rather than in this flow.

Quiet hoursRegion comes off the Lead. The subflow blocks anything outside the window for that region and returns a ReasonCode, which the flow logs rather than swallows.

One per leadFirst_Auto_Reply_Sent_At__c is checked before the send, so a re-save, a merge or a reopened record cannot trigger a second one.

Opt-out lineCarried in the WhatsApp template. The SMS version fits it inside the same segment.

06 · Reporting afterwards

Speed to lead stops being an argument and becomes a column.

First_Auto_Reply_Sent_At__c minus CreatedDate is the number the rota discussion was really about. A Lead report grouped by source shows it per channel, before and after the rollout.

Inbound leads · first responseLeads

        SourceLeadsMedian first replyReplied
      

Web form4127s31%

Paid ads2886s24%

Chatbot968s44%

Landing page617s28%

MEDIAN FIRST REPLYFirst_Auto_Reply_Sent_At__c minus CreatedDate. The number it replaces was measured in minutes and depended on the hour of day.

REPLIEDLeads carrying at least one inbound Message Bucket. This is the one that predicts a booked call, not the send count.

BLOCKEDLeads where the guardrail returned CanSend = false, grouped by ReasonCode. A rising consent count is a form problem, not a messaging one.

07 · Implementation note

Where ValueText fits.

ValueText is the send action and the inbound handler. It installs from AppExchange as a managed package, adds the Send Message invocable action to Flow Builder, and writes every inbound message as a Message Bucket record and a Task on the Lead. Templates, keyword rules and the org-level send window live in ValueText Setup. The two fields, the flow, the guardrail subflow and the report are yours, built with standard tools, and they keep working if you change the number or the carrier.

Professional edition or above · WhatsApp needs an approved template for the first message · 1 SMS segment per reply at the published per-country rate

AppExchange review

“Valuetext is the outstanding solution to integrate whatsapp and sms into salesforce. The support team can also only be praised in highest tones…”

Cédric BaumgartnerCPO & Co-Founder · AppExchange

This page sits underWhatsApp for SalesforceThe channel page: templates, the 24 hour window and Meta pricing.

In the docs

01 Sending Messages from Flow in SalesforceThe invocable action, its inputs and the test run → 02 WhatsApp Approved TemplatesSubmitting a template and what the 24 hour window changes → 03 Record Linking for First Incoming MessagesHow an inbound reply finds the Lead it belongs to →

Run your messaging inside your CRM.

Rated 4.98 on Salesforce AppExchange

Talk to us Request a sandbox

Reply to a new lead in seconds, before anyone opens the record.

The delay happens before a human ever sees the record.

Three parts, and the flow is the only thing you build.

Add two fields, so speed to lead is a number

Write the first reply once

Fire it on create, not on assignment

The reply is the handover.

Four checks, and they are the same four the rest of the org uses.

Speed to lead stops being an argument and becomes a column.

Where ValueText fits.

Run your messaging inside your CRM.

Reply to a new lead in seconds, before anyone opens the record.

The delay happens before a human ever sees the record.

Three parts, and the flow is the only thing you build.

Add two fields, so speed to lead is a number

Write the first reply once

Fire it on create, not on assignment

The reply is the handover.

Four checks, and they are the same four the rest of the org uses.

Speed to lead stops being an argument and becomes a column.

Where ValueText fits.

Run your messaging inside your CRM.

Reply to a new lead in seconds, before anyone opens the record.

The delay happens before a human ever sees the record.

Three parts, and the flow is the only thing you build.

Add two fields, so speed to lead is a number

Write the first reply once

Fire it on create, not on assignment

The reply is the handover.

Four checks, and they are the same four the rest of the org uses.

Speed to lead stops being an argument and becomes a column.

Where ValueText fits.

Run your messaging inside your CRM.

Reply to a new lead in seconds, before anyone opens the record.

The delay happens before a human ever sees the record.

Three parts, and the flow is the only thing you build.

Add two fields, so speed to lead is a number

Write the first reply once

Fire it on create, not on assignment

The reply is the handover.

Four checks, and they are the same four the rest of the org uses.

Speed to lead stops being an argument and becomes a column.

Where ValueText fits.

Run your messaging inside your CRM.

{{ page.h1 }}

{{ page.breaks.h2 }}

{{ page.pattern.h2 }}

{{ p.title }}

{{ page.replies.h2 }}

{{ page.guardrails.h2 }}

{{ page.reporting.h2 }}

Where ValueText fits.

Run your messaging inside your CRM.