# Send through a Twilio Messaging Service, not a hardcoded From number
The first Twilio SMS tutorial hardcodes a From number. That is fine for one message and a trap for everything after.
## Procedure
1. Create a Messaging Service in the console.
2. Add your senders to its sender pool: long codes, short codes, toll-free numbers, alphanumeric sender IDs. Mix types for resilience.
3. Point your code at the Messaging Service SID instead of a From number. The create-message call takes a messaging service SID in place of the from number.
4. Turn on Sticky Sender so a conversation's replies keep coming from the same number. Users get confused when each reply arrives from a new number.
5. Configure a fallback sender so a failed or deprovisioned sender does not drop the message.
6. Use the built-in opt-out management for STOP and HELP keywords instead of building your own keyword parser.
## Why not just a number
- No failover: if the number is down or gets flagged, every send fails.
- No scaling: throughput limits attach per sender; a pool spreads load.
- Compliance attaches to the campaign behind the service (10DLC), not to any single number. Moving numbers in and out of the pool does not disturb compliance.
- Geomatch and sender selection (area code matching, country routing) only exist at the service layer.
Keep one hardcoded number around for local dev if you like, but production code paths should only ever reference the service SID.