Case Study
·
Exotel
Digital and inbound growth at Exotel
2021–23 · Organic search, paid acquisition, website conversion and buyer evaluation
I worked on digital and inbound growth at Exotel from 2021 to 2023. A larger share of my day-to-day sat around organic search and the website, alongside paid acquisition and the reporting needed to understand what those programmes were producing further down the funnel.
It was also a period of substantial change for the company. Exotel entered 2021 primarily as a cloud communications business. It merged with Ameyo that June, expanding into enterprise contact centre, and acquired Cogno AI in November, adding conversational AI, live chat and co-browsing capabilities. At the time of the Ameyo merger, the combined business reported roughly $45M ARR, a presence across 60 countries and more than 500 large Indian enterprises using either Exotel or Ameyo.
Over that period, the wider inbound system improved. More relevant demand entered the funnel, more of it became qualified volume, and paid acquisition became more efficient through work across the team.
+~20%
Relevant inbound traffic
Directional
+~40%
Inbound MQLs
Directional
+~55–60%
Inbound SQLs
Directional
-~22%
Paid cost / SQL
Programme
The aggregate figures describe where the wider inbound system moved during the period. Exotel was also adding products, entering broader categories and changing other parts of GTM at the same time. The rest of the case stays closer to the analyses, programmes and experiments I was directly involved in.
Historical company metrics are rounded or indexed. Working views and experiments are reconstructed to preserve the relationships and decisions in the historical work rather than reproduce old internal dashboards.
I use four labels throughout the case to distinguish what kind of evidence each result is based on.
Diagnostic
Evidence used to decide what to change.
Experiment
Comparable variants.
Programme
Movement observed around a campaign, query family or page programme.
Directional
Aggregate system movement while wider company changes were happening too.
Starting point
At one point, MQL-to-SQL was holding around the mid-30s. We weren’t seeing an obvious deterioration in qualification further down the funnel.
The more immediate constraint was the amount of qualified inbound entering it.
SQLs = Relevant visits × (Visit → Lead) × (Lead → MQL) × (MQL → SQL)
A representative starting point looked roughly like:
For paid acquisition:
Cost / SQL = Paid spend / Paid sourced SQLs
An MQL here means a lead that met the fit and intent criteria used for marketing qualification. Relevant traffic means acquisition traffic to commercial surfaces in the markets we were working on, rather than every session anywhere on exotel.com.
The gap could be worked on in several places.
We could bring in more relevant traffic. We could improve how much of the traffic we already had converted. We could also change the mix of demand entering the funnel so that more of what converted subsequently qualified.
At that point, acquisition still had meaningful headroom. Paid search gave us a relatively fast read on which kinds of demand were qualifying. Organic search was slower, but could build longer-lived acquisition around commercially useful demand we were otherwise repeatedly paying to reach. I spent more of my time on the organic side.
Conversion work became more interesting wherever useful intent was already arriving but the page receiving it was losing too much of that intent.
Those became connected parts of the same problem rather than separate channel goals.
Growing relevant demand
Organic search
The search backlog was much larger than the amount of work we could sensibly do at once.
Search volume was useful, but it wasn’t enough to decide the order.
Where we had paid data for the same or adjacent query families, qualification gave us another signal. Some searches repeatedly brought in commercially useful demand when we paid to capture them while Exotel’s organic coverage around the same problem was weaker.
There was also the changing product surface to account for. Cloud telephony, IVR, APIs, SMS and number masking were established parts of Exotel. During the period, the offering broadened into contact-centre, conversational-AI and other digital-engagement capabilities.
So the backlog contained categories Exotel already had reason to defend, commercially useful gaps we could strengthen, and newer categories where we were still learning how strongly to invest.
Search opportunity analysis
Diagnostic
The products and use cases are grounded in Exotel’s product footprint during the period. The exact historical coverage states and commercial-signal bands are reconstructed.
The sheet helped decide where to investigate. It did not tell us what the solution should be.
For a priority query family, the next question was usually what was actually preventing us from competing for it.
SEARCH DIAGNOSTIC
What was preventing a priority query from competing?
The opportunity sheet identified where to investigate. This diagnostic determined the kind of intervention.
COMMERCIAL SEARCH OPPORTUNITY
↓
DECISION
Does a viable destination exist for this intent?
NO
Build or reshape the right surface
Create a destination aligned to the query and the buyer’s job.
YES
Diagnose the existing surface
01 · Relevance
Page/query fit · content depth
02 · Delivery
Technical health · performance · internal linking
03 · Competitive strength
Relevant backlinks · SERP competition
That meant similar-looking search gaps could produce quite different work.
For IVR, an existing commercial surface might need a clearer query focus, stronger treatment of IVR flows and routing, better internal links from adjacent pages, or deeper product and proof inputs with content and PMM.
For number masking in logistics, the capability already existed. The work was more about making the commercial job recognisable. Someone searching for number masking in a delivery workflow did not need to decode a generic cloud-telephony proposition before finding the relevant capability.
Exotel had already documented this use case publicly. Ecom Express had integrated Exotel’s number masking into its delivery application so that customers and delivery associates could call through a virtual number without seeing one another’s personal phone numbers.
For cloud contact centre, the situation was different. The underlying product itself had expanded.
Making newer product capabilities easier to evaluate
The Ameyo merger expanded what Exotel could offer. Alongside cloud telephony and communications APIs, the company could now enter broader contact-centre evaluations.
That started showing up in acquisition too. We were seeing searches around cloud contact-centre software and related enterprise use cases, and some of those cohorts were commercially promising.
The existing acquisition experience did not always explain the newer offering with the same specificity.
For someone evaluating a contact-centre platform, a broad cloud-communications proposition left several practical questions unanswered:
What can agents actually do?
How does routing work?
What does it integrate with?
Can it support an enterprise deployment?
What reporting is available?
How does the telephony layer fit with the contact-centre product?
So on the acquisition surfaces I worked on, the message needed to organise those communication capabilities around the job the buyer was evaluating.
Message shift
SEARCH + PRODUCT LANGUAGE
Keep the terms buyers search and recognise.
Cloud communications
Voice
SMS
IVR
APIs
REFRAME
LEAD WITH THE BUYER JOB
Run customer conversations across a distributed contact centre.
SOME OF THE PROOF NEEDED
Routing
Route conversations to the right agents.
Integrations
Connect CRM and business workflows.
Operations
Manage agent workflows and reporting.
Beyond those examples, the page also needed to answer questions about deployment, enterprise use cases, technical evidence, support and scale.
I worked on how this product story showed up in the digital acquisition and evaluation surfaces I was responsible for, collaborating with PMM and content where deeper product context was needed. My part was making the product and competitive story clearer on those surfaces, not defining Exotel’s positioning.
Supporting search work
Some priority pages had problems underneath their content or message.
We used Ahrefs and Semrush to audit broken internal paths, stale destinations, redirect gaps, crawl and indexation issues, internal-linking opportunities and the external-link landscape around commercial pages we wanted to compete with.
The useful broken-link work was practical. We fixed paths into pages we wanted people and crawlers to reach, updated links after pages moved, and used redirects where a genuine replacement existed.
For selected commercial pages, external links and distribution were part of the work too. I scoped the priority pages and the kinds of opportunities that were relevant. Parts of prospecting and outreach were supported by freelancers, then reviewed for relevance and quality.
We did monitor authority-type scores in SEO tools as diagnostics. The work itself was aimed at improving Exotel’s ability to compete around pages that mattered commercially, rather than moving a proprietary authority score for its own sake.
Paid acquisition
Paid search gave us a faster way to add demand and also made differences in demand quality easier to see.
Broader campaigns could look attractive near the top of the funnel. They had more available volume and often produced leads more cheaply than narrower product or use-case campaigns.
I split search activity into query families and followed those cohorts further through MQL and SQL.
Paid-search analysis
Diagnostic
+38%
CPL
→
-28%
Cost / SQL
CPL and cost/SQL are independently indexed to the cloud-telephony cohort = 100.
The specific-use-case cohort is a useful comparison.
Its leads cost roughly 38% more than the broad cloud-telephony cohort. Around half subsequently met the MQL threshold rather than roughly a third, and MQL-to-SQL progression was stronger again.
By SQL, the more expensive-looking lead was approximately 28% cheaper.
That gave us a reason to change the account itself.
Changing the paid mix
ACCOUNT STRUCTURE
From one broad account to intent-led groups
BEFORE
One broad campaign
Mixed category, product and use-case searches
Shared message and broad destination
Weak queries were harder to isolate
AFTER
Cloud telephony
Core category intent
IVR / routing
Product-specific intent
Logistics / privacy
Delivery and number-masking intent
Cloud contact centre
Product-specific evaluation
Negatives / exclusions
Repeatedly irrelevant or consumer intent
Query family → message → destination
Separating productive query families gave us more control over bids and budgets, but it also made the experience more coherent.
Ads could speak to the problem behind the query. Their destination could continue the same context. Search-term reviews surfaced recurring intent we could stop paying for, while the narrower structure made it easier to see when additional spend started pulling a strong programme into weaker queries.
When creative capacity was tight, I built some campaign assets directly in Figma and worked with an external creative partner on larger sets. That was simply part of getting the campaigns out with the intended message intact.
Deciding how far to scale each programme
Once the paid mix was cleaner, the harder question was how far we could scale each campaign group before the additional traffic became less qualified or more expensive.
The lowest historical cost per SQL didn't always get the next budget increase.
Retargeting to previous site visitors could be efficient but was limited by the audience already available.
Specific product and use-case search had more room, but additional spend eventually meant more expensive auctions or weaker neighbouring queries.
Broad category campaigns could absorb much more money but had weaker downstream economics.
For productive search families, I increased spend while checking whether new search terms still resembled the cohorts that had qualified well. Broader campaigns went through recurring search-term and qualification reviews. Retargeting expanded until the available audience made further spend less useful.
Programme result
PROGRAMME MOVEMENT
+18%
Paid spend
+51%
Paid SQL volume
−22%
Cost / SQL
Paid MQL volume
100 → ~138
MQL → SQL
~31% → ~34%
Cost / MQL
100 → ~85
For newer programmes, MQL and SQL progression gave us an earlier read. Once cohorts had had enough time to mature, opportunity and pipeline behaviour provided another check on whether apparently similar SQLs continued to behave similarly commercially.
Improving what happened after relevant demand arrived
Acquisition work also surfaced places where relevant people were already arriving and the next constraint sat further into the experience.
That included how buyers evaluated the product, how closely landing pages matched the acquisition context, and whether removing apparent friction actually improved qualified conversion.
Buyer evaluation
A software buyer did not necessarily move neatly from Google to an Exotel page to a demo.
Research from the period reflects that. TrustRadius found that the average B2B technology buyer used 6.9 information sources during a purchase. Product demos, vendor websites and user reviews were among the most-used sources.
A journey could involve search, Exotel product/use-case pages, comparison research, G2/customer reviews, retargeting or direct return, and eventually a demo.
That made our own comparison pages, product and use-case surfaces, and third-party proof related parts of the same evaluation.
Comparison and alternative pages
Two superficially similar searches could represent different stages of evaluation.
Knowlarity alternative
suggested that the buyer knew one vendor and was deciding what else belonged in the consideration set.
Exotel vs Knowlarity
suggested that both vendors were already being evaluated.
Their volume could be much smaller than a broad category query. The person behind the search was also much closer to a vendor decision.
For the page itself, I worked from the things an evaluator needed to understand: APIs and integrations, IVR and routing flexibility, privacy and number masking, reliability, reporting, setup, support, scale and relevant use cases.
The useful page needed to make the important differences understandable and support its claims with the right technical, customer or third-party evidence.
EVALUATION PAGE BLUEPRINT
Turn vendor comparison into a decision path
The page followed the evaluator’s questions in the order they needed answers.
01
REQUIREMENT
What communication setup are you evaluating?
Anchor the page to the buyer’s use case.
02
DECISION CRITERIA
What matters for that setup?
APIs + integrations, IVR / routing, privacy, reliability, support and scale.
03
COMPARISON
How do the options differ?
Where Exotel is stronger, where distinction is smaller, and which differences matter by use case.
04
EVIDENCE
What makes the claims credible?
Technical information, integrations, customer and use-case proof, and third-party validation.
05
NEXT STEP
Evaluate Exotel for this requirement
This work sat at the intersection of search and product marketing. It required translating product capabilities into criteria buyers actually used while evaluating vendors, then matching claims to technical, customer or third-party evidence.
Comparison-page visitors tended to qualify better than broad product traffic. I treated that primarily as evidence about the intent of the cohort. Someone actively comparing vendors is already different from the average product-page visitor.
For the page programme itself, a reconstructed same-query-family view showed visitor-to-MQL improving by roughly 20–25% after the evaluation experience was strengthened.
Programme
QUERY INTENT
Similar searches, different decision distance
The query wording signalled how much of the vendor decision had already happened.
CONSIDERATION SET
“Knowlarity alternative”
The buyer knows one vendor and is deciding what else belongs in the set.
DECISION STAGE
Vendor discovery
SHORTLIST COMPARISON
“Exotel vs Knowlarity”
Both vendors are already being evaluated; the buyer is closer to a decision.
DECISION STAGE
Direct comparison
PROGRAMME READ
Same query-family reconstruction
+~20–25%
Visitor → MQL
G2 and third-party proof
G2 served a different job from an Exotel-hosted comparison page.
On our own site, we could explain the product and make an argument. On a review platform, a buyer could read customer feedback somewhere the vendor did not control in the same way.
G2 was one of the evaluation surfaces we worked on. Exotel had customer reviews there, and G2 recognition and badges could also be brought back onto relevant Exotel pages as third-party proof.
The badge itself wasn’t particularly interesting. Its useful job was to sit beside product claims, customer evidence or a conversion surface and give the evaluator another signal beyond Exotel talking about itself.
There is no clean isolated funnel lift attached to this work.
Mechanism:
third-party proof → support buyer evaluation
Direct evidence:
presence / reviews / recognition + proof used on site
Isolated funnel movement:
not measured
Landing-page diagnosis
Seeing a weaker conversion rate told us where to investigate. It did not tell us why the page was weak.
For selected acquisition pages, I combined quantitative funnel cuts with the journey that had brought the visitor in and behavioural diagnostics such as heatmaps, scrolling and click behaviour.
A representative diagnosis included:
Quantitative signal:
high-intent traffic but weaker-than-expected page conversion
Journey review:
specific query / ad → broader destination
Behavioural evidence:
attention concentrated earlier in the page important use-case content reached later interaction spread across unrelated routes useful proof beyond major attention drop
Hypothesis:
carry the acquisition context further into the landing experience
The heatmap wasn’t the conclusion.
The acquisition context showed what the visitor had come for. Behavioural evidence helped show how people were interacting with the page. The funnel showed where the loss appeared.
Together, those gave us something concrete to test.
Returning to number masking
The number-masking journey is a useful example.
Someone arriving through:
number masking for delivery
already had a relatively specific job in mind.
The broader destination made that visitor work through a much wider Exotel proposition before reaching the workflow they cared about.
The revised experience carried much more of the acquisition context into the page.
INTENT-MATCHED EXPERIENCE
From broad proposition to delivery workflow
BEFORE
Broad cloud-telephony proposition
Several capabilities compete
Voice, SMS and other products share attention.
Number masking appears later
The visitor must decode the broader proposition first.
Broad proof and next step
Evidence and CTA are not specific to delivery.
AFTER
Number masking for last-mile delivery
Protect customer and delivery-agent phone numbers during every call.
Customer
→
Exotel virtual number
→
Delivery agent
Neither party sees the other’s personal number.
PROOF
Relevant logistics example
INTEGRATION
Delivery app → Exotel API / virtual number → masked call
NEXT STEP
Evaluate number masking for the delivery workflow
The change went beyond a headline. It altered what appeared first, how the capability was explained, which evidence accompanied it, and how much unrelated product context the visitor had to move through.
Landing-page A/B test
On one high-intent campaign cohort, we tested a broader experience against one built more tightly around the acquisition context.
Experiment
The additional submissions continued through qualification instead of disappearing immediately afterward.
That gave us a reason to apply the same approach to other journeys where the acquisition intent was similarly clear.
A form test that moved the wrong combination of terms
On another campaign page, the form itself looked like a possible source of friction.
Behavioural and form diagnostics gave us a reasonable hypothesis that reducing the effort required to submit would increase completion.
We tested removing several fields.
The shorter form did what the hypothesis expected at the first step. More people completed it.
Those additional submissions qualified at a lower rate, leaving the amount of qualified demand produced by the same traffic almost unchanged.
Experiment
We didn’t extend the shorter version more broadly.
Website performance
Some acquisition problems sat underneath the campaign, message or page hierarchy.
Several commercially important surfaces were slow. They were receiving paid traffic and were also expected to compete through organic search, so the shared delivery layer affected more than one acquisition programme.
Performance audit
Programme
Page load:
~8s → ~4s
The work included compressing or replacing heavy assets, using lighter formats where appropriate, improving caching, expanding CDN delivery with engineering, and reducing avoidable weight in shared page templates.
Page delivery sits before the rest of the acquisition experience. A visitor has to reach and interact with the page before its message or conversion path can do anything. Page experience was also an active search concern during the period. Google’s mobile page-experience update rolled out between June and August 2021, with the desktop rollout following in February and March 2022.
Directly measured:
Page-load reduction on the affected surfaces
Potential downstream path:
delivery → interaction / search
Isolated funnel lift:
not separately measured
Search and conversion continued to be monitored around those pages as part of the broader programme. The directly observed result from this piece of work was the performance improvement itself.
Measurement
For the channel-level reporting reconstructed in this case, each lead or SQL has one sourced home so paid, organic and other channels can be compared without counting the same outcome several times. The source is an operating convention, not a claim that the rest of the journey contributed nothing.
ATTRIBUTION MODEL
Reporting view ≠ buyer journey
REPORTING VIEW
One sourced channel per outcome
Campaign, query and page remain available for analysis.
Source / campaign / query / page
↓
Spend
↓
Relevant traffic
↓
Lead
↓
MQL
↓
SQL
↓
Opportunity
↓
Pipeline
REAL BUYER JOURNEY
Several touches can contribute
An illustrative path - not a required sequence.
Organic comparison visit
↓
G2 / research
↓
Retargeting
↓
Use-case page
↓
Direct return
↓
Demo
↓
SQL
One source keeps reporting additive. It does not claim that the journey was single-touch.
Several people from the same company could also take different paths before one account eventually became an opportunity.
Overall movement
DIRECTIONAL SYSTEM VIEW
How the acquisition system moved
More relevant traffic and stronger conversion at each handoff increased qualified volume.
SYSTEM MOVEMENT
Relevant visits
100 → ~120
+~20%
Visit → Lead
~0.9% → ~1.0%
↑
Lead → MQL
~45% → ~48%
↑
MQL → SQL
~34% → ~38%
↑
RESULTING VOLUME
Inbound MQL volume
100 → ~140
Inbound SQL volume
100 → ~155–160
COMBINED EFFECT
Traffic growth and stronger handoffs compound into qualified volume.
Indexed volumes and rounded stage rates.
Digital/inbound-sourced pipeline also moved materially upward during the period.
These are aggregate company-level movements. The narrower programme and experiment evidence above is more useful for assessing the contribution of individual initiatives.
How the work maps back to the model
What I’d set up differently now
I would preserve lifecycle-stage history more deliberately from the beginning. A lead’s current stage tells us less than knowing when it entered and left each stage, how long progression took and how that differed across acquisition cohorts.
I’d bring company-level reporting alongside contact-level reporting earlier too. Several people from one company can arrive through different searches, ads, reviews and pages while the eventual commercial outcome belongs to one account.
For paid acquisition, I’d feed qualified CRM outcomes back into campaign optimisation earlier. We were already using MQL and SQL progression to decide where budget should move, so using those outcomes in the optimisation signal would close more of that loop.
And where an experiment’s important outcome eventually becomes company-level, I’d be more deliberate about assignment. Visitor-level randomisation works well for visitor behaviour. It becomes harder to interpret when several people from one company receive different experiences before a single account later progresses.