SMS categories under DLT
Classify the message before writing the template.
OTP, transactional, service, and promotional SMS are not just labels. The category affects sender headers, consent context, template wording, variables, provider controls, and the API payload your application sends.
Many DLT problems begin before the portal is opened. The team writes a message first, adds variables later, and only then asks whether it is transactional, service, or promotional. That order is backwards. The message category should be decided before the template is written and before the API payload is designed.
This guide explains how to think about OTP SMS, transactional SMS, service messages, and promotional SMS in a practical DLT workflow. It is not legal advice and it does not replace current operator or TRAI instructions. It gives business and development teams a cleaner way to plan templates.
Official source note: TRAI's sender guidance lists sender requirements such as principal entity registration, header registration, content template registration, consent registration, and requirements for bulk communications. Confirm category-specific rules with the current portal and provider guidance: TRAI Advice to Senders.
Category-first planning
Quick answer
Separate SMS categories before template registration.
A good DLT planning session should separate:
- OTP and security messages, such as login codes and password reset codes.
- Transactional or critical account notifications, depending on the business context and portal category options.
- Service implicit messages triggered by a customer action, such as order updates.
- Service explicit messages that rely on a consent or relationship context, such as reminders.
- Promotional messages, such as offers and campaigns, which usually need stricter preference, scheduling, and consent controls.
Category map for business SMS
Use category planning to prevent mixed-intent templates:
| Message example | Typical intent | Planning focus |
|---|---|---|
| Login code | Account security | Fixed OTP wording, short expiry, no offer copy. |
| Order shipped | Service update | Order ID, status, delivery link, customer action source. |
| Appointment reminder | Service reminder | Consent or relationship context, date and time variables. |
| Payment receipt | Transaction record | Amount, invoice ID, receipt link, no unrelated promotion. |
| Discount campaign | Promotion | Campaign controls, preference handling, timing, and consent review. |
The label alone does not make the message safe. The actual wording, trigger event, consent path, and provider controls matter.
OTP and transactional SMS
OTP SMS is usually high-priority because it affects login, signup, payment authorization, and account recovery. Keep it narrow.
OTP SMS planning checklist
- Use an approved header connected to the product or business.
- Keep message body focused on account access or authorization.
- Use variables for code and expiry only where possible.
- Avoid campaign copy, discounts, or unrelated service text.
- Test delivery, sender display, expiry timing, and failure behavior.
- Log failed sends in the application without storing sensitive codes longer than required.
For developers, an OTP template should be a stable contract. The code should not generate alternate copy based on campaign state, referral source, or marketing rules.
Service implicit and service explicit SMS
Service messages are usually tied to a customer relationship or action. Examples include order confirmations, ticket alerts, appointment reminders, invoice notices, and delivery updates.
Start from the order event
The template should map to a clear event such as confirmed, packed, shipped, delivered, or cancelled.
Document the reminder basis
Clinic, salon, and service reminders should record where the appointment came from and whether explicit consent handling is needed.
Do not turn receipts into campaigns
A receipt can include amount, invoice, or link details. Mixing offers into the same template creates intent confusion.
Variables follow the business event
If the business event has order ID, status, date, and link, the template variables should mirror those values.
Promotional SMS and campaign controls
Promotional SMS requires a more cautious operating model. Campaigns are often time-bound, audience-targeted, preference-sensitive, and content-heavy. The template and provider setup should reflect that.
Promotional planning controls
| Control | Why it matters | Owner |
|---|---|---|
| Consent or preference basis | Confirms why this recipient should receive the campaign | Business or marketing owner |
| DND and schedule handling | Avoids sending outside allowed or expected controls | SMS provider and operations |
| Template copy approval | Keeps campaign wording aligned with registered content | Marketing and DLT owner |
| Unsubscribe or preference workflow | Supports customer communication hygiene | Business owner |
Do not reuse an OTP header or template for campaigns. Keep campaign workflows separate so production code cannot accidentally mix intents.
API impact of category decisions
The category affects implementation:
- Different headers may be used.
- Different templates may be required.
- Consent template references may be needed.
- Provider API fields may change.
- Scheduling, DND, or route controls may apply.
- Reporting and failure handling may need different operations review.
Developers should receive a final category map before building the SMS service abstraction.
FAQ
Is OTP SMS considered separate from promotional SMS?
Yes, treat OTP as a security or account access flow. Do not blend offers or campaign language into OTP messages.
Can order alerts and appointment reminders use the same template?
They should usually be separate because the business event, variables, and consent context differ.
Who should decide SMS category?
Business, operations, and development should decide together. The final choice should be checked against current portal and provider guidance.
Can Shinka help classify messages before DLT registration?
Yes. Shinka can build a message inventory, classify flows, prepare templates, and map approved IDs into the SMS provider API.
