What a capped user experiences
The usage-cap plan, start to finish · Android only · live settings as of 31 Oct
Heavy users are moved to a weekly call limit
Equal is free until a user starts using it a lot. When they open the app, we look at how many calls the assistant handled for them in the last 7 days:
- More than 30 calls → usage cap, at any account age.
- Account 3+ days old and more than 20 calls (more than 13 if the account is under a week old) → usage cap.
- Lighter users (about 14–20 calls) get the other paywall instead: no call limit, but recordings and transcripts are locked. Not covered on this page.
- New since 29 Oct: half of brand-new users on phones worth ₹25,000+ start on the usage cap from day one.
20 calls a week, resetting every 7 days
The assistant answers up to 20 calls a week. The week starts on the day the user was put on the cap and resets every 7 days from then, not on a fixed weekday. Failed calls and the "Meet your Assistant" demo call don't count. Call recordings are locked the whole time, even before the limit is reached.
A pop-up on the home screen counts them down
Once they've used 20% of the week's calls (4 of 20), a sheet pops up on the home screen: "16 out of 20 Calls Left", a usage meter, "Your calls quota reset in N days", the plan and price, and a Get Equal AI Unlimited button. It gets more urgent at 50%, 80% and 90%.
Limit reached: the assistant stops answering
From the next call on, calls ring straight on the phone, as if Equal weren't there. No screening, no summary, until the week resets. At this moment the user gets three signals:
- In the app: the sheet changes to "Weekly Limit Reached" ("Your Assistant handled all 20 of your calls this week").
- On the home screen: a banner stays up: "Weekly call limit reached · resets in N days · Get Unlimited".
- On WhatsApp: the message this dashboard tracks, with their first name and their reset date. Sent within seconds, or at 9 AM if it's night. Skipped if they're already paying or opted out.
Unlimited straight away
Tapping Get Unlimited (in the app, or by opening the app after the WhatsApp message) leads to the paywall. They pick a plan (most choose ₹119), set up UPI AutoPay through Razorpay, and the limit lifts immediately: the assistant answers again and recordings unlock.
Wait for the reset, and the cycle repeats
Calls keep ringing through until the 7 days are up. Then they get 20 fresh calls, the countdown starts again, and if they hit 20 again they get another WhatsApp message (at most one per week). Over half of cap hits now come from users on their second week or later.
Behind the scenes: how the WhatsApp message gets sent
Plain-language version · technical names in the right column
The call system notices the 20th call
When a call ends, our backend counts it against the user's week. If that call took them across 25%, 50%, 75% or 100% of the limit, it announces it once. The announcement is just a fact, "this user used X of their 20 calls". It doesn't say who to message or how.
usage.free_limit_consumedusage.event.free_limit_consumedThe messaging system picks it up
Our messaging service (comms) hears every announcement but acts only on the 100% one. The 25/50/75% ones are ignored for WhatsApp. It receives about 98% of what Mixpanel records.
free_limit_consumed_whatsappIt fills in what it needs to know
It looks up the user's phone number and first name, and asks billing: is this user already paying?
subscriptionsIt decides whether to send
It doesn't send if the user is already paying, opted out of our WhatsApp messages, has a number that recently bounced as "not on WhatsApp", or already got 3 messages from us today. If it's between 9 PM and 9 AM, it waits until 9 AM.
eai00comms-decision-log00prodIt double-checks, then sends
Right before sending, it checks again that the user still hasn't paid, which matters for the 9 AM sends. Then it sends the approved utility template with the user's first name and reset date from our number +91 81253 97474, through our WhatsApp provider Karix.
android_monetization_free_calls_used_up_utilityeai00comms-send-ledger00prodWhatsApp reports back
WhatsApp tells us whether the message was delivered or read, or why it failed. Users who turned off read receipts never show as "read", even if they saw it.
eai00comms-webhook-receipt00prodWe look for a payment within 7 days
The message has no button and no tracking link, so we can't see the tap. Instead we check billing for a new subscription paid within 7 days of the message.
subscription_transactions (first charge)Headline
For the selected days
Funnel
Big number = share of the step before · every cap hit in the range
Where users drop off
Pick a step. The reasons add up to that step's loss exactly.
Does the message cause payments?
Messages that reached the phone · payments within 7 days
Payments by hour, relative to when the message was sent
Each bar = first charges in that hour. Hour 0 is the hour the WhatsApp message went out. Users were already capped before hour 0, so if the message did nothing the bars would stay flat.
Messaged vs couldn't be messaged
Paid within 7 days of the cap hit. "Couldn't be messaged" = opted out, number marked unreachable, or the send failed. Not a random holdout, so read it as direction, not exact lift.
How fast the message goes out
From comms receiving the cap hit to the WhatsApp send
Why most messages wait 0 seconds and some wait overnight
There's no deliberate delay on this message. Comms sends it the moment it receives the cap hit, unless that's between 9 PM and 9 AM IST. Then quiet hours push it to 9 AM. Users who pay before 9 AM are re-checked at send time and skipped.
The event_id carries a timestamp, but it's the start of the user's weekly cap period, not the cap hit. Measuring from it suggested a ~90h delay that doesn't exist. The median 90h is actually how long users take to use up their free calls.
Who pays: by how fast they used up the free calls
Reached messages, 7-day paid rate, by time from week start to cap hit
Why the paid rate fell (≈1.6% → ≈0.9%)
Analysis snapshot, 31 Oct · messages that reached the phone · paid within 7 days
| Period | What was live | Messages | Repeat share | Start checkout | Starters who pay | Paid ≤7d | First-timers paid | Paid with discount |
|---|---|---|---|---|---|---|---|---|
| 26 Aug – 7 Sep | Launch. Two prices (₹159 / ₹199). Half of users had the 25%-off coupon applied automatically. Weekly limit cut 30 → 20 on 2 Sep. | 35,012 | 17% | 16.0% | 9.8% | 1.61% | 1.72% | 63% |
| 8 – 15 Sep | Everyone moved to the ₹159 plan. | 33,054 | 41% | 11.7% | 10.4% | 1.26% | 1.46% | 56% |
| 16 Sep – 9 Oct | Coupon auto-apply switched off (16 Sep). Users must type EQUAL25 themselves. | 111,630 | 55% | 9.3% | 11.1% | 1.09% | 1.48% | 30% |
| 10 – 23 Oct | Entry rules loosened: accounts 3+ days old (10 Oct), the "any age" bar lowered from 40 to 30 calls (17 Oct), 13+ calls for accounts under a week (23 Oct). EQUAL50 (₹79) for older non-payers from 19 Oct. | 107,107 | 54% | 7.5% | 11.6% | 0.92% | 1.15% | 35% |
More of the cap hits are repeat weeks (≈25% of the drop)
Users who don't pay hit the cap again the next week, and the week after. Repeat weeks went from 17% to 54% of all messages. They pay at ~0.75%, about half the rate of a first-time cap hit, and their checkout starts fell from 14% to 5%. These are mostly people who already said no once.
First-timers dropped on 8 Sep, when everyone moved to ₹159 (1.72% → 1.46%)
Checkout starts among first-timers fell from 16% to 13% the same week. This also lines up with the end of the launch burst (on 2 Sep the limit dropped to 20, so many long-time users hit it for the first time at once). Without a holdout, the two can't be separated.
usage_cap_plans_exp_prod: 33/33/33 → 100% ₹159 on 8 Sep 04:16 UTC.Turning off coupon auto-apply barely moved conversion, and raised revenue
After 16 Sep, first-timers converted at the same rate (1.46% → 1.48%), but far fewer used the discount (59% → 32%). People mostly paid full price instead of leaving. This change looks like a win.
coupon_autoapply prod 50% → 0% on 16 Sep 14:22 UTC.First-timers dropped again from 10 Oct, when entry rules were loosened (1.48% → 1.15%)
Letting in newer and lighter users brought ~60% more cap hits, but each converts less. Account age alone doesn't explain it: the drop shows up in every account-age group. The 30–40-calls-a-week users added on 17 Oct are the likely low-intent group. Confirming it needs per-user call counts.
usage_cap_experiment_config versions 10, 16, 17, 23 Oct.Checkout starts use a random 25% of users (by user-id prefix), since the read replica cancels larger reads. All other numbers use every user. Dates come from Statsig version history.
Day by day
Paid rate only for days with a full 7-day window
Definitions
How each number is counted
- Cap hit: one
usage.free_limit_consumedevent at threshold 100 received by comms (one per user per weekly cycle). Dated by the IST day of comms' first decision. - Comms allowed it: the final verdict (dispatch stage, or t0 if it never got that far) is "send". "Waiting for 9 AM" = deferred and not sent yet at the data cut.
- Reached the phone: send record status is delivered or read. "Sent, no delivery receipt" = Karix accepted it but no delivered/failed report came back.
- Read: send record status = read.
- Paid within 7 days: the user's first charge on a new subscription (
paid_count = 1), more than 0 and at most 7 days after the message was sent. Messages sent less than 7 days before the data cut are counted as "Too recent". Revenue = that first charge. - Sources: comms decision log + send ledger (DynamoDB, prod), billing_prod read replica, code at comms-service main and user-services main.