How to Let Users Choose When and How Often an AI Contacts Them
People should be able to decide whether an AI contacts them, which kinds of messages it may send, and when those messages can arrive. A useful design starts with an explicit opt-in, lets people set a schedule and frequency, separates genuinely different message types, and keeps pause and off controls easy to find. It also explains the selected time zone and what may affect delivery. These controls make a clear promise; the product’s scheduling and delivery systems must be able to keep it.
Start with a clear, optional opt-in
Ask for permission when a person can understand what they are agreeing to. Describe the kinds of contact in plain language: for example, a reminder the person requested or a periodic update. Say where it will arrive and how often it may be sent. Avoid an unexplained operating-system permission prompt as the only explanation; people need to know what the app wants to send before deciding.
The U.S. Web Design System advises collecting contact preferences only for channels a service can actually support, and says to explain the conditions and expected timeline for contact when possible. Applied to an AI product, that means showing only real delivery options and stating what each one is for. Do not make a notification preference a condition for using unrelated features. USWDS: Contact preferences
Treat opt-in as a choice the user can revisit. Apple’s notification guidance recommends a clear opt-in or opt-out for notification types and an in-app way to manage notification settings. A product can follow that principle with a settings page that summarizes the current choices, rather than making someone search through unrelated device settings to understand the app’s own schedule. Apple: Managing notifications
Make the schedule concrete
Let people choose a window that fits their routine, such as weekdays between 6 and 8 p.m., or a recurring time on selected days. Show the days and the start and end times together. If the control sets a “contact window,” explain whether a message may arrive at any point inside it or at a specific time. If there is no eligible message on a given day, say whether the system skips that day or carries the message forward.
A practical design can offer a few understandable presets, such as “once a week” or “weekdays,” while allowing a custom schedule where the product supports it. A preset should resolve to a visible schedule, not an ambiguous label. For example, “weekly” should display the chosen day and time, and “up to three times a week” should say whether three is a ceiling or a target. This is a design recommendation: the platform documentation supports scheduled delivery, but the product team must decide and describe its own sending rules.
Be precise about time zones. Label the schedule with a named location or the device’s current local time zone, and tell users whether the schedule follows them when they travel or stays anchored to the original zone. A bare UTC offset can become misleading when daylight-saving rules or government time-zone rules change. IANA’s time-zone database records rules for locations and is updated to reflect changes made by political bodies, including changes to offsets and daylight-saving rules. IANA: Time Zone Database
A good confirmation might read: “Tuesdays at 7:00 p.m. in your current local time. This schedule follows your device’s time zone.” That wording is only accurate if the implementation actually tracks the user’s current zone. If the schedule remains fixed to a selected zone, name that location instead. When a person travels or the device’s zone changes, show the effective schedule and provide a way to review it.
Separate message types and channels
People may want one kind of contact and not another. Keep optional reminders, product updates, and other distinct categories separately selectable, rather than bundling them into one “AI notifications” switch. Do not invent categories that have no corresponding product behavior, or create a category as a pretext for sending messages the user did not select.
This separation also aligns with platform controls. Android requires notifications to be assigned to channels on modern versions, and users can change channel behavior; Android’s guidance recommends channels that let people customize the notifications they receive. The app can name channels in terms people recognize, such as “Scheduled reminders,” and describe what belongs in each. Android Developers: Create and manage notification channels
Keep the channel list short enough to understand. A channel should represent a meaningful choice a person might want to make independently. The product’s own settings should still explain the content and schedule: operating-system channel controls can alter whether or how a notification appears, but they do not explain the app’s sending policy or replace an in-product schedule.
Put pause, resume, and off controls within reach
Offer a temporary pause and a permanent off switch. A pause should make its duration explicit—such as until a chosen date or until the user resumes—and show whether scheduled messages are skipped or held. An off control should state which categories or channels it affects and confirm the changed state immediately. Resuming should not silently restore a previous schedule without showing what will happen next.
Make these controls available from the notification settings screen and, where practical, from a notification action or a direct settings link. Android supports actions in notifications and gives users system-level ways to manage future notifications; its controls vary by device and Android version. Therefore, an in-app route remains useful for showing the full schedule and changing product-level preferences. Android Developers: Notifications
Device-level controls still matter. A user can turn off an app’s notifications or change channel behavior at the operating-system level, independently of the app’s own schedule. The interface should not imply that an in-app setting overrides those choices. If system notifications are disabled, show a clear status when the user visits settings, and avoid repeatedly prompting them to re-enable notifications.
Set a frequency limit the system can enforce
Give people a direct frequency choice: for example, one message per day at most, a weekly maximum, or a user-selected number of days. Define the counting period and what counts as a message. If multiple categories can send messages, clarify whether the limit applies per category or across the whole product. A per-category limit can still produce a high combined volume, so a useful design often includes an overall cap as well.
A cap only works if every outbound path observes it. Check scheduled reminders, retries, delayed messages, and messages initiated by different features against the same preference state. If one message is delayed, decide whether it expires, arrives later within the permitted window, or is dropped; explain the behavior that matters to the user. Avoid sending several missed messages at once after a device reconnects unless the user explicitly chose that behavior.
Platform delivery is not the same as a product’s sending decision. Firebase Cloud Messaging says messages are typically delivered immediately, but a device may be unavailable or delivery may be delayed; the service can store a message and attempt delivery later within its configured lifespan. That means a product should not promise that every notification will appear at an exact minute. It can promise to schedule a send within a stated window, while explaining that device and platform conditions may affect when it appears. Firebase: Set the lifespan of a message
This distinction also affects frequency. If a notification was queued and arrives late, the system should check whether the user has since paused or turned that category off, and whether sending it would exceed the current cap. A truthful design cancels or suppresses stale queued messages when the user’s latest choice makes them ineligible.
A simple decision sequence for the design
Use this sequence to turn the settings into a user-understandable commitment:
Name the message types the product can actually send, and make each optional category understandable.
Ask the user to opt in to each desired category and delivery channel. Do not preselect optional contact.
Let the user choose days, a time or window, and a maximum frequency. State whether the cap is overall or per category.
Display the time zone and say whether the schedule follows the user when their device zone changes.
Make pause, resume, and off controls visible, then show the current state and the next eligible contact time.
Before delivery, recheck the schedule, cap, pause status, and category preference. Treat device delivery as potentially delayed, and describe the product’s promise in terms it can control.
A compact settings summary can make the arrangement easy to verify: “Scheduled reminders: on. Tuesdays and Thursdays, 7–8 p.m. local time. Maximum: two per week across all categories. Pause or turn off anytime.” The exact options should reflect real capabilities; if a product cannot enforce the displayed cap or follow local time reliably, it should change the implementation or narrow the claim before presenting that control.