Growth OS
One plan, carried out across every channel
Most of what goes wrong in marketing automation goes wrong between deciding and doing: the send that went twice, the budget change that was approved on Monday and applied against Thursday’s limits. Execution is built around those two failures.
14-day evaluation · no card · start before you connect anything
One change, from approved to verified
- 1
Claimed once
Taken by exactly one worker, so it cannot run twice.
- 2
Re-checked at the moment of action
Permissions and limits are asked again — hours may have passed since approval.
- 3
Applied on the platform itself
Not in our copy of it. The platform is the source of truth.
- 4
Read back
Confirmed where it can be. A failure to look is recorded as unverified — never as matched.
How it works
Where this sits in the loop
Execute. It does the work. It follows Approve and hands on to Measure.
- 1
Work is claimed once
Every piece of queued work is taken by exactly one worker through an atomic claim. Two workers cannot both believe they own a send, which is the mechanism that stops a campaign going out twice.
- 2
Limits are re-checked at the moment of action
An approval is not a permit that never expires. When work is actually applied, the permissions, the limits and the trust rules are checked again — because hours may have passed and none of them is guaranteed to still hold.
- 3
Only safely repeatable failures are retried
Setting a budget to a figure can be retried; sending an email cannot. Each kind of action declares which it is, and the retry logic obeys that rather than treating every failure the same way.
- 4
The change is read back where it can be
After a change is applied, Xyranik reads it back from the platform to confirm it is there. Crucially, a failure to look is recorded as unverified — never as matched. Not knowing and knowing are different states.
What you get
One campaign across channels, measured in one place
Email, texts, posts and ads that belong to the same campaign are tracked as one thing, so what it cost and what it returned are answerable without stitching four reports together.
Automations run the version that was live
When an automation is turned on its steps are frozen as a version. A run follows the version that was live when it started, so editing never changes a run already under way.
Rehearse before turning it on
An automation can be run against one of your real contacts as a dry run, showing the path it would take without doing anything.
What it does not do
Listed here rather than discovered later.
Some platforms can be read but not written to
Where a platform’s API does not support a change, Xyranik says so at the point of proposing rather than accepting the proposal and failing later.
Delivery figures depend on the provider
What was accepted by a provider and what was delivered are different numbers, and Xyranik shows the one it actually has. Some delivery data only appears once the relevant webhook is configured.
Give it a goal and watch what it proposes
Nothing reaches a customer or spends money without you. The evaluation starts before you connect anything, so you can read what it would do before deciding whether it may.