Submission speed and delivery speed are different things, and most "SMS is slow" tickets dissolve once the two are separated.
Your bind has a rate
Your connection has an agreed throughput (messages per second). Submit faster than that and messages queue on our side - they are not lost, they are waiting. Sustained submission above your rate grows the queue and the tail latency; the fix is either pacing your submission or agreeing a higher rate.
Destinations have rates too
Some destination networks throttle inbound international SMS, and registered routes in regulated markets sometimes carry per-sender rate limits. A campaign that submits in one burst can deliver over a much longer window on such destinations - that is the destination's policy, not queue misbehaviour.
Campaign hygiene that avoids the ticket entirely
- Tell us in advance about large campaigns or televoting-style bursts: expected volume, destinations, window. We pre-clear the fraud controls (bursts look like spam floods to monitoring) and confirm the route can take the rate - see "Fraud controls on wholesale traffic".
- Spread submission across the window rather than front-loading.
- Watch your DLR return rate during the send - a healthy campaign shows DLRs flowing steadily behind submissions.
Reporting a throughput problem
Include: submission timestamps and rate, message IDs from the start and end of the affected window, destination(s), and whether DLRs eventually arrived (slow) or never arrived (something else - see the DLR guide). If the queue is on our side we will say so and show you the drain rate.