Conversation OS
Start free
All posts

Guide

India DLT SMS and WhatsApp CRM

VartaDesk

India DLT SMS and WhatsApp CRM on one desk: Entity ID, Template ID, Header, category, opt-out, and why incomplete DLT must never silently send.

Someone checking a phone on the commute — in India the reminder that actually arrives at 7:05 am is often SMS.
Someone checking a phone on the commute — in India the reminder that actually arrives at 7:05 am is often SMS.

If you sell in India, “WhatsApp CRM” is only half the reach problem. The reminder that actually arrives at 7:05 am — parent on a bus, WhatsApp notifications muted, child already in school — is often SMS.

SMS in India is not a free-text playground. It is DLT: Distributed Ledger Technology under TRAI. You are a Principal Entity (or you send via one). You have registered Headers (the 6-character sender ID people see). You have Template IDs. You have a category. If those values do not match the portal, operators park the traffic. Your CRM looking green does not impress the operator.

A SMS and WhatsApp CRM that ignores DLT will either fail at send time (good) or send unregistered traffic (career-limiting). VartaDesk treats DLT as a gate on SMS template sends, not a footnote in a help article.

Two rulebooks, one customer

WhatsApp and SMS share a person. They do not share a regulator.

WhatsApp (Meta) cares about the 24-hour customer-care window, template approval, commerce policy, and quality rating on the WABA. A utility template is not a marketing template. Variables must match what was approved.

SMS (TRAI / DLT) cares about:

  • Principal Entity registration
  • Header / Sender ID (typically 6 characters, registered)
  • Template ID for the exact registered body
  • Entity ID
  • Category (transactional, service, promotional — use what you registered, not what marketing wished)

VartaDesk stores Entity ID, Template ID, Header and category on the SMS template. Incomplete DLT can sit on a draft so a pack can install copy. It cannot go out through the send chokepoint. Free-form SMS, where a vendor still allows it, is a different path. Template SMS is not.

A phone showing a message thread — the CRM must not invent a Header to make onboarding look fast.
A phone showing a message thread — the CRM must not invent a Header to make onboarding look fast.

What goes wrong in the wild

  1. Copy-paste from WhatsApp. The WhatsApp body has `{{1}}` and a footer. The DLT template is a different registered string. Operators compare against the ledger, not your intent.
  2. Header typo. `VARTAD` vs `VARTDA`. The portal has one. Your CRM has the other. Everything “looks saved.”
  3. Promotional content on a transactional header. You will not win that argument with the operator.
  4. Pack-invented IDs. A vertical pack that ships fake Entity IDs so the demo feels complete is a compliance landmine. VartaDesk will not do that. Drafts yes; pretend-registered Headers no.
  5. Ignoring STOP. DLT is not a licence to keep messaging. Global opt-out and SMS opt-out still win at the chokepoint.

Why this keyword is worth a page

Generic “WhatsApp CRM” articles never mention Entity IDs. CPaaS vendors talk connectivity. WhatsApp inboxes talk shared chat. The query India DLT SMS CRM is what a founder types after the first failed campaign and an angry SMS vendor email.

If you also need the WhatsApp side of the same desk, start from the product. Coaching centres: WhatsApp CRM for coaching institutes and add SMS reminders on the same student record.

Practical setup (in order)

  1. Register on the DLT portal before you write CRM copy. Entity, headers, templates. Get the IDs on a sheet the ops lead owns.
  2. Connect an SMS vendor that actually supports DLT — Fast2SMS DLT routes, Twilio with Indian DLT, etc. VartaDesk is the desk; the vendor is the pipe.
  3. Paste IDs character-for-character into the SMS template in VartaDesk. Do not “clean up” spacing.
  4. Keep WhatsApp templates on their own approval lifecycle. Two registrations, two bodies, two variable lists.
  5. Test to a handset you control, then to a small internal list, then to customers. Do not debut DLT on a 40,000-row festival blast.
  6. Wire opt-out. STOP, and the CRM flags, must block enqueue — not merely look sad on a report.
A support headset on a desk — when SMS fails, the parent still calls; the CRM should already know the thread.
A support headset on a desk — when SMS fails, the parent still calls; the CRM should already know the thread.

How VartaDesk enforces this

On an SMS *template* send, incomplete DLT is blocked before quota and before the worker talks to the vendor. WhatsApp, RCS and email are exempt from DLT fields. Incomplete DLT is allowed on save so you can draft and so packs can install templates without lying about registration.

If you are comparing vendors, ask them to fail a send with a blank Template ID in a demo. If they shrug and “it still goes,” that is not a desk you want in production.

FAQ

Can I use the same text for WhatsApp and SMS? You can start from the same meaning. You cannot assume the same registered template. Register twice.

Do I need DLT for WhatsApp? No. Different universe. Do not paste Entity IDs into WABA fields.

What about RCS? Not DLT in the TRAI SMS sense. Still a separate channel with its own vendor rules.

We only message people who gave us a number on a form. Consent is necessary and not sufficient. DLT still applies to the route. Opt-out still applies to the person.

Our BSP said they handle DLT. Some do, on their console. If your CRM is the system of record for templates, the IDs still have to live there or you will drift.

Onboard SMS in the knowledge base, or see pricing if you want the desk and the DLT fields in one place.

SMS & RCS guide Start free