The Markin ROI Report for Enterprise Growth TeamsRead now
MARKIN

Markin + Twilio integration

SMS and WhatsApp as an arbitrated surface.

What is a Twilio AI agent?

A Markin and Twilio setup uses Twilio as the transport for decisions that need SMS, WhatsApp or voice. Markin decides who is worth contacting and with what, and calls Twilio only when the expected value clears the cost of the message.

Messaging is the channel where over-contact costs the most. Arbitration before send is worth more here than anywhere else, and holding is treated as a valid decision.

Decision APITriggered event

What Markin reads

  • Delivery receipts and reply events
  • Opt-in and opt-out state

What Markin writes back

  • Send instructions with the chosen action, or an explicit hold

How the connection works

Activation patterns used with Twilio
PatternWhat it means here
Decision APIThe surface asks Markin for a decision at render time and receives one action plus its reason, with a defined fallback.
Triggered eventMarkin emits an event that starts or advances a journey. Near-immediate, and the channel keeps its own governance.

What can you ask Markin to do in Twilio?

  • How do I decide which customers are worth an SMS?
  • Can I trigger Twilio messages from a churn model?
  • How do I reduce SMS spend without losing retention?
  • How do I measure the incremental value of WhatsApp campaigns?

What Markin does in Twilio

  1. 01Read delivery, reply and opt-out events.
  2. 02Price each candidate message against its expected return.
  3. 03Suppress contacts whose expected value is below the send cost.
  4. 04Call the messaging API with the decided content reference.
  5. 05Respect quiet hours and consent held in your own systems.
  6. 06Maintain a randomised holdout among contactable customers.
  7. 07Read conversions back keyed to the decision ID.
  8. 08Report cost per incremental euro of revenue.

Scope of work

The growth work behind Twilio

The list above is what Markin touches in Twilio. A connector is only the surface. Below is the work itself: what an analyst, a lifecycle manager, a data scientist and an experimentation lead would do between them, running continuously against your own data.

Read the estate

Normally a data engineer, once, then never refreshed.

  • Read contact history so past sends count as pressure on the customer.
  • Track catalogue, pricing and plan changes as they happen.

Find where revenue is leaking

Normally a quarterly analyst deep dive.

  • Spot pricing and packaging mismatch between what people buy and what they use.
  • Spot product friction that correlates with downgrade and cancellation.

Explain why

Normally a two-week investigation pulled off the roadmap.

  • Keep the query trail so an analyst can reproduce every number.
  • Run the investigation automatically and return the drivers with their evidence.

Write hypotheses worth funding

Normally a workshop, limited to the ideas in the room.

  • Write hypotheses continuously across marketing, product, pricing and technical health.
  • Attach the expected revenue effect and the population it applies to.

Decide per customer

Normally segment rules refreshed when someone has time.

  • Arbitrate between every action competing for that same customer.
  • Apply frequency caps, fatigue and quiet hours before anything is committed.

Execute in the tools you already run

Normally a ticket, then a slot in next month's calendar.

  • Write decisions into the CRM, engagement and warehouse systems already in production.
  • Trigger journeys and campaigns that your lifecycle team owns and can edit.

Prove it caused the revenue

Normally argued about, rarely measured.

  • Hold back a randomised control group on every decision, not one global holdout.
  • Read uplift in revenue per customer against that control.

Retire, govern and hand over

Normally nobody's job, so nothing is ever switched off.

  • Show the whole decision trail when legal, finance or an auditor asks.
  • Hand the team a portfolio they can read, question and overrule.
See the full scope of work Markin runs

Teams use Twilio together with

Twilio questions

How does Markin connect to Twilio?
Decision API, Triggered event. The surface asks Markin for a decision at render time and receives one action plus its reason, with a defined fallback.
What does Markin read from Twilio?
Delivery receipts and reply events; Opt-in and opt-out state.
What does Markin write back into Twilio?
Send instructions with the chosen action, or an explicit hold
Do we have to move our data to Markin?
No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later.
Does Markin replace our engagement platform or CDP?
No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout.
What if the system we use is not listed?
The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days.

Connect Twilio and read the first holdout.