Automation Best Practices in IZI: How Not to Spam Your Clients

Automation Best Practices in IZI

Automation is a powerful tool that is easy to overuse. Too many rules, too-frequent notifications, overlapping conditions — and instead of improving the client experience you get annoyed clients who disable notifications. This section is a hygiene guide for automations.

Principle 1 — Client Value as a Filter

Before creating any rule with a notification, ask yourself: will the client be glad to receive this message?

Send	Don’t Send
Bonus awarded (client received something)	On every session end without a bonus
New rank reached (significant event)	On every small balance deduction
Reactivation offer after long absence	More than three reminders in a row
Welcome message on first visit	Technical notifications with no client value

A notification should be an event, not noise.

Principle 2 — Frequency Limits

IZI has no automatic frequency limiter at the platform level — the responsibility lies with the club owner.

Maximum per session: 1–2 notifications. If on session end a client can receive a cashback notification, a rank notification, and a top-up bonus notification — that’s three messages per visit. Pick the most important one or combine them.

Maximum reactivation messages: 2 per cycle. Day 14 and day 30. After two attempts with no response — the client has left; further pings won’t help.

Time buffer between notifications of the same type: if a client received a reactivation notification, returned, and went dormant again — the next reactivation notification should not come before the new interval (14 days). Implemented by properly removing “dormant” groups on return.

Principle 3 — Anti-Spam Rule Architecture

Separate audiences with conditions. If the top-up bonus applies to everyone but the bar cashback applies only to the “Gold” group, add a group condition to the cashback rule. Without conditions the rule applies to everyone — this may not be what you intended.

Check event overlaps. For each event (Session ended, Balance top-up, etc.) review all active rules with that event. If two rules fire on the same event without separating conditions — the client will receive both actions.

Overlap checklist:

Event	All Active Rules	Overlap Check
Session ended	List all rules	Are there two rules without mutually exclusive conditions?
Balance top-up	List all rules	Do two rules award bonuses for the same top-up?

Use mutually exclusive conditions for tiers. In a tier system, rules for each tier must have mutually exclusive hour ranges. Silver: ≥ 10 AND < 50. Gold: ≥ 50. Without an upper bound for Silver, a client with 60 hours will fall under both rules.

Principle 4 — Testing Before Full Rollout

Test on one club. When creating a rule, specify a particular club in the “Clubs” field — the rule will only operate there. Run a few test operations, check the firing history.

Test client. Keep a separate account for testing (your own phone number or a colleague’s). Always test new rules on the test client before removing the club restriction.

History check. After a test operation: Automation → rule → History tab → check status (Completed / Skipped / Error). Status “Completed” with correct conditions = rule is working.

Principle 5 — A/B Testing

There is no native A/B testing in IZI, but it can be organized manually.

Via groups:

1. Create two groups: “Test A” and “Test B”
2. Split similar clients between groups (e.g., first half of alphabet in A, second in B)
3. Create two rule versions — one with condition “Group = Test A,” the other with “Group = Test B”
4. Run both rules simultaneously for 2–4 weeks
5. Compare: number of firings, client metrics from each group (returns, top-ups)

What to test:

• Bonus size (50 vs 100 bonuses for first session)
• Bonus expiry period (14 days vs 30 days)
• Notification text (emotional vs neutral)
• Reactivation interval (14 days vs 21 days)

Minimum test duration: 2–4 weeks, preferably identical days of the week in both periods. Shorter — too few events for conclusions.

Principle 6 — Rule Set Management

Rule naming. A clear name saves time during diagnostics. Format: “[Category]: [Action] — [Condition].” Examples:

• “Rank: Gold — assignment”
• “Bonus: 10% on top-up from 500”
• “Reactivation: 30 days without visit”

Grouping with descriptions. Use the “Description” field in the rule for context: when created, what problem it solves, until what date it should run (for temporary promotions).

Regular audit. Once per quarter: open the full rule list. For each rule, answer three questions:

1. Is this rule still needed?
2. Is it firing as often as expected?
3. Is there another rule doing the same thing?

A rule that doesn’t fire is either outdated or misconfigured. Unnecessary rules are technical debt and a source of unexpected overlaps.

Principle 7 — Client Opt-Out

Clients manage notifications at the device level. IZI has no built-in “unsubscribe from marketing notifications” in the profile — this is an iOS/Android system setting.

Recommendations:

• In the club FAQ, describe how to disable notifications (Device Settings → Apps → IZI → Notifications)
• Don’t try to work around disabled notifications
• If a client asks “no promotions” — remove them from the relevant groups (e.g., from a group that receives promotional notifications)

A client who disabled notifications but keeps coming is more valuable than a client irritated by spam.

Principle 8 — Action Order Within a Rule

With multiple actions in a rule, order matters. Recommended:

1. Remove old groups (if tier system)
2. Assign new group
3. Award bonuses
4. Send notification — always last

Notification last because by the time the client opens the app, all preceding actions are already complete: rank updated, bonus awarded. The client sees the current state.

Pre-Launch Checklist for a New Rule

• Trigger event is correctly selected
• Conditions don’t allow the rule to fire for unintended clients
• Action order is logical (bonus → notification)
• Rule name is self-explanatory without context
• Rule tested on a test client
• Overlaps with other active rules for the same event checked
• For a temporary promotion — end date noted in description
• If testing — restricted to one club

Quarterly Audit Checklist

• All active rules have clear names
• No rules with zero firings in the past month (except exceptional scenarios)
• No duplicate rules with the same event and similar conditions
• Temporary promotions disabled after ending
• No more than 3–4 active rules per event

Typical Mistakes

Mistake	Signal	Solution
Too many notifications per visit	Clients complain about spam, disable notifications	Keep max 1–2 notifications per session
Old promotion rules forgotten and still running	Outdated text in notifications	Quarterly audit, disable temporary rules by date
Double bonus awards	Clients receive more than expected	Check condition overlaps for rules on the same event
Unclear rule names	Can’t quickly understand what a rule does	Rename to “[Category]: [Action]” format

See Also

• Automation in IZI: Overview
• Push Notifications: Campaign Setup
• Segmented Broadcasts
• Anti-Churn Automation
• Rule Firing History