Devotel Orbit is a CPaaS — the messaging platform where a ten-person team sends SMS, WhatsApp, RCS, and email from one workspace. Template libraries in those workspaces grow quietly: every campaign, every experiment, and every quick composer save leaves a template behind, and after a year nobody knows which ones still fire. Pattern usage analysis is the operator's answer to that — a deterministic way to find the templates that never fire, group message bodies that are effectively the same thing, and clean the library without eyeballing raw logs.
What shipped
Pattern usage analysis is a tenant-owned read over your own message library. It clusters repeated message bodies so an operator can hunt dead templates — templates that exist in the Message Templates hub but no send actually uses — deterministically, rather than scrolling through logs and guessing from names. If you've ever archived a template named promo_final_v3 and hoped nothing still pointed at it, this is the feature that turns the hope into a check.
Two properties of the feature frame the whole post. First, it is read-only: it reads the message and template rows your workspace already carries and surfaces groupings — it neither deletes nor pauses anything. Second, it is deterministic: the same library at the same moment produces the same groupings, so when the analysis says a template body has no usage pattern, that is a statement you can act on, not a probability.
Pattern usage analysis is announced on the Devotel Orbit changelog and reachable from the Announcements hub; the docs registered against it carry the day-to-day runbook. This post is the explainer for both.
What clustering means
A template library rarely drifts one body at a time — it drifts in families. A team edits "Your appointment is tomorrow at {{time}}" into "Reminder: appointment tomorrow at {{time}}" for one campaign and keeps both. A copy-campaign duplicates a body and changes only the sender. Over a year the list shows twenty entries that are, in practice, four message families. Reading raw logs person-by-person does not survive that shape; clustering does.
Clustering means the analysis groups message bodies that match according to its deterministic grouping rules. Instead of receiving a flat list of templates to scan one row at a time, you see each recurring body as one group — so an operator reviews the four families, not the twenty rows. The same deterministic grouping applies to every body the analysis reads, which is what makes the rest of the workflow repeatable: given the same library, the same clusters come back.
The per-cluster output is the working surface. The analysis runs over your template library and surfaces callouts — the flagged rows a human should look at first. A callout is not an automated action; it is a pointer. The most common callout shape is the dead template: a template body no send pattern uses. The second common shape is the near-duplicate cluster — bodies the deterministic grouping puts together, where an operator can collapse the family back into one maintained template. In both cases the callout says "look here" and the operator decides; nothing in the cluster itself touches the library.
A worked dead-template hunt
Here is the workflow an operator runs once a quarter, end to end.
- Start from what the analysis surfaced. Open the pattern usage analysis view and read the per-cluster callouts first — they are the deterministic shortlist, ordered so you do not read the whole library.
- Pick a dead-template callout. A callout marks a body no send pattern uses. The worked example: your library holds
winback_2023_offer, an old campaign body. If the cluster reports no usage for that body, the template is a candidate — not yet a conclusion. - Confirm against the library. Open the Message Templates hub, find the template, and check it the way you'd check any candidate before acting. Deterministic analysis narrows the scan; the operator still eyeballs the candidate before the archive.
- Archive, don't delete. Pause or archive the template. The send side already helps: the composer hides paused and archived templates from its Use Template picker, and won't preload one from an old bookmarked link — so once archived, the template stops appearing where a sender would pick it, and reactivating it returns it to the composer as before.
- Repeat per cluster. Work the remaining callouts. Because the analysis is deterministic, a re-run after cleanup shows the same groups minus what you archived — so the next quarter's pass is small.
The same hunt generalizes past one bad template: the cluster view is also how you find the four-family drift from the prior section. If the deterministic grouping puts five bodies together and four of them have no usage, the one you keep becomes the maintained template — one name, one body, one owner.
What the analysis does not tell you
Pattern usage analysis answers one question — is this body used — and it answers it deterministically. Keep the adjacent questions out of its scope; they live in other surfaces.
Deliverability is not a pattern. The analysis cannot tell you whether a body that does fire is reaching handsets, being filtered, or underperforming. "This template is used" and "this template works" are different claims; only the first is a pattern statement. If what you actually need is the delivery side, that lives in the delivery and analytics surfaces of the workspace, not in the usage cluster.
A never-used body is not automatically junk. For example, a body you are staging for a launch next week legitimately has no usage yet. The deterministic rule cannot tell intent; it can only tell you the send pattern is empty. That is exactly why the workflow keeps its confirm step human; an operator who knows the staging calendar treats a never-fired body as a question, not a delete instruction — and why the safe action is archive (reversible), not delete.
The cluster is not a compliance verdict. Pattern usage analysis is a library-hygiene tool. It does not read a body for regulatory content, and a cluster that survives cleanup is not thereby TCPA-quiet-hours-consent-clean. Compliance review stays a separate pass with its own surfaces.
Frequently asked questions
What does "deterministic" mean here?
It means the analysis groups message bodies by deterministic grouping rules, not by a model's judgment. The same template library at the same moment produces the same clusters and the same callouts every time, which is what lets an operator treat the callout list as a work queue: a body the deterministic grouping reports as never used stays never used on a re-run, until either your library or your sends change.
Does the analysis change any template when it runs?
No — it is read-only over the message and template rows your workspace already carries. The only writes in the whole workflow are the ones you make on the candidate template afterward (pause or archive it) in the Message Templates hub.
Why archive instead of delete?
Archive is reversible and it already gates the send path: the SMS composer hides paused and archived templates from its Use Template picker, and it won't preload one from an old bookmarked "use this template" link either. So the moment you archive a template, it stops being something a sender can pick by accident — and if the hunt was wrong, reactivating returns it to the composer exactly as before.
If clustering is deterministic, why keep a confirm step?
Because "never used" is a fact and "safe to remove" is a judgment. The deterministic grouping hands you the candidate list; the operator still checks intent — a staged campaign body, a holiday template kept for next season — before touching anything. The analysis narrows the library to the rows worth eyeballing; it does not remove the eyeball.
Where do I read the announcement or the runbook?
The Announcements hub carries the pattern usage analysis entry and links the changelog announcement from it; the registered docs carry the operator runbook. Start from Announcements and follow the entry.