Nobody plans a messy template library. It happens because templates cannot be edited after approval — every change is a new template — so libraries grow by accretion, and by template thirty nobody is sure which one production actually sends.
The constraint that causes the mess
An approved template is immutable. Fixing a typo means creating a new one, getting it approved, pointing your code at it, and deciding what to do with the old one. Do that a dozen times without a convention and you get exactly the sprawl everyone ends up with.
Name them systematically
Template names allow lowercase letters, numbers and underscores. Use that deliberately: domain_purpose_variant_version.
order_shipped_default_v3order_shipped_international_v1booking_reminder_24h_v2cart_recovery_first_v4
The version suffix is the important part. It makes the newest obvious at a glance and it makes deprecation safe, because you can leave the old one in place while traffic moves across.
Names to avoid, all of which we have genuinely seen in production libraries: test, test2, final, final_final, new_one, ashish_template. Six months later nobody knows what any of them do, and nobody dares delete them.
Keep a register outside the platform
The template list in any dashboard tells you the name, category and status. It does not tell you which system sends it, who owns the copy, what it superseded, or whether it is still in use. Keep a simple sheet with a row per template:
- Name and version
- Category and languages
- What triggers it, and from which system
- Owner — a person, not a department
- Status: active, superseded by, or retired on
- Approval date
Ten minutes to set up, and it is the difference between a confident cleanup and never daring to delete anything.
Retire deliberately
When a replacement is approved, point production at it, wait a full billing cycle, confirm the old template has zero sends, then delete it. Deleting immediately risks a scheduled job or a rarely-run flow still referencing it — a failure that surfaces weeks later at the worst moment.
Languages multiply everything
Each language is a separate approval under the same template name. Three languages across twenty templates is sixty approvals to manage. Two habits keep it sane: add languages only where you have real volume, and never let translations drift in meaning from the source, because a category judgement made on the English version does not automatically hold for a looser Hindi rendering.
Consolidate before you add
Before creating a new template, check whether an existing one differs only in wording. Two templates saying the same thing slightly differently are a maintenance cost with no benefit — and a smaller library sends more volume through each template, which produces cleaner data on what actually performs.