Specialist third parties that reliably deliver transactional messages, receipts, OTPs, alerts, at scale.
Why it exists
Delivering email and SMS reliably means dealing with carriers, spam filters, and deliverability that no product should build itself. Email and SMS services exist as specialists you send through, so your messages actually arrive without you running mail and telecom infrastructure.
How it actually works
Sending email or SMS reliably (past spam filters, across carriers, at volume) is a hard, specialized job, so companies use providers like SendGrid or Twilio through their APIs. Your backend hands them the message and recipient; they handle delivery.
These are usually triggered by background workers and are the delivery layer behind receipts, one-time codes, and alerts.
A senior PM walks you through it
A junior PM, stuck
Support is flooded with "my OTP never arrived" complaints for last night's logins, so eng sent me the SMS provider's delivery log to triage. It is a screenshot of about ten lines with words like queued, sent, delivered, undelivered and some numbers like 30003. I do not know whether this is our bug, the provider's fault, or the customers' phones, and I have to tell support something.
This is the provider's own record of what happened to each text we handed it, and it separates the three things you just listed. The key is that a message moves through statuses, queued to sent to delivered, and where it stops tells you exactly who to blame. "Sent" is not "delivered," and that one distinction answers most of these tickets. This is a different lens from our OTP service log: that one shows the code's life on our side, this one shows the message's life on the carrier's side. Here are the lines. Read the status on each, then take the steps with me.
Reporting "we sent all the codes" from the sent lines. Sent means handed to the carrier, not received, so a wall of undelivered can hide behind a healthy-looking send count.
Blaming our app or the OTP service for a 30003. That code is the carrier saying the handset was unreachable, which no change on our side can fix for a powered-off phone.
Treating the four-minute-late delivery as a success because the status is delivered. For a login code, on time is the requirement, so a late delivered is a failed login from the customer's chair.
Having no fallback when a number keeps returning 30003. If SMS cannot reach a customer at all, the only real fix is another channel like voice or email, and that is a product decision, not a retry setting.
Escalating to the provider without the sids and error codes. "SMS is broken" gets a shrug, while "SM71b and SM71d ended undelivered with 30003, SM71c delivered four minutes late" tells them exactly which sends to look up.
Tell support: "Read the delivery log by final status. The two undelivered ones are carrier error 30003, an unreachable handset, so those are phone-side and no resend will help. One delivered but four minutes late, which is why that customer still complained. This is a deliverability and latency issue, not codes going missing, so let us look at a voice or email fallback for repeat 30003 numbers." You triaged by last status instead of by send count.
Where a PM meets this
Deliverability is a real issue, receipts and OTPs that land in spam or never arrive cause support load; provider choice affects this.
These services cost per message and carry sending reputation; "why did our emails start going to spam" is a genuine, ownable problem.
Hear it in a meeting
"OTPs are slow because the SMS provider's queue is backed up."