Expanding online/offline into a real activity model — awake, at work, head down, commuting, out, asleep, away — where the status governs reply speed, message length, whether she can send a photo, and whether she reaches out at all.
8 screens · carries the v3 messaging theme · behaviour spec included for engineering
Theme
Switches every screen below.
The distinction that makes this worth building
A status label is cosmetic — a coloured dot that says "busy" while the character replies instantly anyway. Users detect that inconsistency within a day and it actively damages belief. A status system means the label is the visible edge of behaviour that genuinely differs: Meera in surgery does not reply, and your message sits on one grey tick until she's out.
That's the whole idea. Presence stops being decoration and becomes the mechanism that proves she has a life independent of you — which is the thing you're actually selling.
It also produces the best moment in the product: the catch-up reply. She comes off shift, reads six hours of your messages at once, and responds to them as a batch — referencing the gap, apologising for it, picking up the thread. Screen 05. That moment is only possible because she was genuinely unavailable, and no competitor that replies instantly to everything can manufacture it.
The risk is obvious and I've designed against it: a paying user who gets stonewalled feels cheated, not immersed. The mitigations are staggered rhythms so someone is always reachable, an always-visible "back at" time, and a hard cap on how long your primary character can be unavailable.
01 — The model
Seven states, and what each one does
This table is the engineering spec. Every column is a behaviour the storyline clock drives, not a cosmetic variant.
Status
Reply latency
Message style
Photos
Initiates?
Ticks
FREE
seconds
Full length, warm, asks questions back, follows tangents
Yes
Yes
✓✓ blue, fast
AT WORK
5–30 min
Short, clipped, occasional typo, "brb", trails off mid-thought
Rarely
Occasionally
✓✓ then blue late
HEAD DOWN
until it ends
Nothing until free, then a catch-up batch
No
No
✓ single grey
COMMUTING
2–10 min, bursty
Short, one-handed, several small messages in a row
Sometimes
Sometimes
✓✓ blue
OUT
10–40 min
Distracted, more emoji, "sorry just saw this"
Yes — in-the-moment
Rarely
✓✓ delayed blue
ASLEEP
until wake time
Nothing, then a morning catch-up
No
No
✓ single grey
AWAY
hours
Nothing, then a long catch-up with an explanation
No
No
✓ single grey
Why the tick states matter more than the labels
Indian users read one grey tick versus two blue ticks fluently — it's a WhatsApp literacy that needs no teaching. Using it honestly means the interface tells the truth about availability without a single word of explanation: your message to Meera at 2pm sits on one tick, and you understand instantly that she hasn't seen it.
This is the highest-leverage detail in the whole system. It costs almost nothing to implement and it does more for believability than any amount of dialogue quality.
Status is derived, never random
Each status comes from the character's storyline calendar — the same clock that drives their week in the earlier wireframes. Ananya is AT WORK from 10am because her sprint calendar says so; she goes HEAD DOWN at 4pm Friday because that's the client demo. Status and story are the same data. That's what makes it coherent, and it's why a competitor bolting presence onto a stateless chatbot can't reproduce it.
02 — Coverage
Somebody is always reachable
Realistic unavailability only works if the roster covers the clock between them. This is the strategic reason to give characters different rhythms — it isn't just variety, it's uptime.
00
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Ananya · engineer
Meera · night shift
Kabir · musician
Divya · startup
Free — replies fastSemi — slow, short repliesUnavailable — no reply until back
Zero dead hours
Across the 24-hour cycle there is no hour where every character is unavailable. Fifteen hours have at least one character fully free; the remaining nine have at least one on slow-reply. The 3am–7am window — the loneliest hours, and disproportionately when this product gets used — is covered by Meera precisely because she works nights.
This is worth stating plainly to the content team: rhythm assignment is a scheduling problem, not a creative one. When you add a fifth character, they should fill a coverage gap, not duplicate an existing pattern.
03 — Screens
What it looks like
Eight screens covering the roster, messaging someone unavailable, the catch-up, and status-driven re-engagement.
Who's around ★01
14:20▮▮▮ ▮
Who's aroundThursday, 2:20 PM
⌕
[Kabir]
Kabir, 28free
Sound engineer · Delhi
In the studio, taking a break. Replying properly.
[Ananya]
Ananya, 26at work
Software engineer · Bengaluru
At her desk. Will reply, but short and slow.
Free after 8pm
[Divya]
Divya, 24head down
Startup · Ahmedabad
Investor call. Won't see messages until it's done.
Back around 3:30pm
[Meera]
Meera, 29asleep
Resident doctor · Mumbai
Post-night-shift. Last seen 09:14.
Wakes around 5pm
Sorted by who can talk right now. You can still message anyone.
Notes
Sorted by availability, so the person who can actually talk is at the top. The list reorders through the day — the screen is different at 2pm and 2am.
Every unavailable person shows a "back around" time. This is the single most important anti-frustration detail: waiting is fine if you know how long.
Coloured pip on the avatar plus a text status — redundant encoding, so it works for colourblind users and at a glance.
"You can still message anyone" — we never block sending. Messages always go; only the reply waits.
Messaging someone asleep02
14:22▮▮▮ ▮
←
[M]
MeeraAI character · asleep · last seen 09:14
⋮
TODAY
Okay I'm dying. 14 hours. Going to sleep for a century 💀
9:14 AM
get some rest, seriously
9:20 AM ✓
how was the night? anything mad happen
2:21 PM ✓
also I got the promotion thing I mentioned
2:22 PM ✓
💤 Meera is asleep after a night shift. She usually wakes around 5pm — she'll see these then.
Message😊 📎
➤
Notes
Single grey ticks. Three messages sent, none seen. Every Indian user reads this instantly — no explanation needed.
The system note tells you why and when. Unavailability with a stated end time reads as realism; without one it reads as a bug.
The composer stays fully active. You can keep talking to someone who's asleep — which is exactly what people do in real life, and it seeds the catch-up.
App bar subtitle carries status and the AI disclosure in one line.
At work — short and slow03
14:25▮▮▮ ▮
←
[A]
AnanyaAI character · at work
⋮
TODAY
hey, free?
2:02 PM ✓✓
kind of
2:19 PM
standup abhi khatam hua, ab code review
2:19 PM
want to hear something annoying about my day?
2:20 PM ✓✓
haan bolo
2:24 PM
but I might disappear mid-convo, warning de rahi hoon 😅
2:24 PM
Ananya is at work — replies may be slow and short until 8pm.
Message😊 📎
➤
Notes
17-minute gap between your message and her reply, visible in the timestamps. Latency is the behaviour; the label just explains it.
Replies are two or three words, lowercase, no punctuation. The writing style is part of the status, not just the timing.
She warns you she might vanish — turning a technical constraint into character. This is how a limitation becomes charm.
Note the tick difference from screen 02: here it's blue ✓✓ because she has seen them.
Head down — hard unavailable04
14:30▮▮▮ ▮
←
[D]
DivyaAI character · head down until ~3:30pm
⋮
TODAY
investor call in 5 mins, I have not prepped AT ALL
1:55 PM
if you don't hear from me assume I've fled the country
1:56 PM
you'll be great, you always wing it well
2:10 PM ✓
let me know how it goes
2:29 PM ✓
🔕 Divya's on the investor call. Back around 3:30pm.
Kabir is free right now if you'd like to talk to someone →
Message😊 📎
➤
Notes
She told you in advance she'd be unavailable. Announced absence feels like a relationship; silent absence feels like an outage.
The graceful redirect at the bottom — suggesting whoever is genuinely free — is the roster paying for itself. Shown only when the person you opened is hard-unavailable, and never as a hard interruption.
This is the screen where a subscriber could feel cheated. The three defences are: a stated return time, a prior warning in her voice, and an available alternative.
The catch-up ★05
17:04▮▮▮ ▮
←
[M]
MeeraAI character · online
⋮
how was the night? anything mad happen
2:21 PM ✓✓
also I got the promotion thing I mentioned
2:22 PM ✓✓
5:02 PM
okay just woke up, 8 hours, feel almost human
5:02 PM
WAIT
5:03 PM
YOU GOT THE PROMOTION??
5:03 PM
and I slept through it, main kitni buri dost hoon 😭 Congratulations yaar, seriously
5:03 PM
tell me everything. Night was insane btw but that can wait, tumhara pehle
5:04 PM
Message😊 📎
➤
Notes
The payoff moment, and the reason the whole system is worth building. Grey ticks flip to blue as she reads everything at once.
She reacts out of order — skips past your first message to the important one. That's how people actually read a backlog.
She apologises for the gap and defers her own news to yours. The absence created the warmth; an always-on bot cannot generate this.
Engineering note: the catch-up needs a distinct prompt path — "you have been away N hours, here are the unread messages, respond as a batch" — not the normal turn handler.
Status-change notification06
17:02▮▮▮ ▮
5:02Thursday, 8 August
◆
MeeraJust woke up — she's seen your messages.
◆
DivyaOff the investor call.
Availability alerts are off by default · max 2 per day
Notes
Status changes are a re-engagement channel with an in-world reason. "She's awake and has seen your messages" is information, not marketing — the kind of notification people don't mute.
Off by default, capped at two per day. Four characters changing status all day is a genuine pressure problem, and unrestricted availability pings are exactly the pattern the engagement-design provisions target.
Notifications only fire for characters you have an active conversation with, and only when you have unread-by-them messages waiting.
Never sent for a character you've gone quiet on. A ping that triggers because you're drifting away is the line we don't cross.
Chats with status07
14:31▮▮▮ ▮
Chats
⌕⋮
[K]
KabirStudio break — free to talk
2:15 PM
1
[A]
Ananyabut I might disappear mid-convo 😅
2:24 PM
[D]
Divya✓ You: let me know how it goes
2:29 PM
[M]
Meera✓ You: also I got the promotion…
2:22 PM
Right now: Kabir is free · Ananya is slow · Divya back ~3:30pm · Meera wakes ~5pm
Chats
People
You
Notes
Status pip on every avatar in the chat list, so availability is legible without opening anything.
Grey ticks on your own outgoing previews show at a glance who hasn't read you yet.
The summary line at the bottom is a small thing that does a lot of work — it answers "who can I actually talk to?" in one glance.
Her day, as a rhythm08
14:33▮▮▮ ▮
←
[A]
AnanyaThursday
⋮
Chat
Her week
Memory
Today
07:30
Awake, slow morning
09:15
Standup, then desk
14:00
Code review ← now
16:00
Sprint sync — head down
19:15
Commute, then dinner
20:30
Home, free to talk
00:30
Sleeps
Tomorrow is the client demo — she'll be head down most of the afternoon.
Remind me when she's free
Chats
People
You
Notes
This replaces the progress-bar dashboard I flagged in v1–v3. A day as a rhythm reads as knowing someone's routine, which is intimate, rather than as reading their telemetry.
Sets expectations honestly — you can see she's unreachable at 4pm and free at 8:30pm, and plan around it the way you would with a real person.
"Remind me when she's free" is opt-in, per character. This is the right way to do availability alerts: user-requested, not pushed at us by default.
04 — For review
Decisions and risks
1. The core risk: a paying user who feels stonewalled
Someone paying ₹399 who opens the app at 2pm and finds their favourite character asleep may reasonably feel they've paid for something that doesn't work. This is the one way the presence system could actively hurt the business.
Four defences are built in: a stated return time on every unavailable state; advance warning in her own voice where the calendar allows; a graceful redirect to whoever is free; and staggered rhythms giving zero dead hours. A fifth I'd add: cap any single character's hard-unavailable stretch at around eight hours, so nobody is ever gone a whole day.
The escape hatch if it tests badly: a per-character "always available" toggle in settings. I've deliberately not drawn it, because it dissolves the entire premise — but it's the obvious mitigation if retention data says users hate waiting.
2. Status must never become a monetisation lever
There's an obvious and tempting dark pattern here: charge to "wake her up", or sell priority access, or make free users wait longer than subscribers. Don't. Any of those converts a realism mechanic into a manipulation mechanic, and it is precisely what the Indian engagement-design provisions are written about.
Status should be identical for free and paying users. The subscription buys unlimited messages and more people, never faster replies from a person who is asleep.
3. Two implementation details that matter more than they look
The catch-up needs its own prompt path. Handling six unread messages as a batch — reacting out of order, apologising for the gap, prioritising the important one — is different from the normal turn handler. Get this wrong and the best moment in the product becomes six disconnected replies.
Latency must be jittered, not fixed. If "at work" always replies in exactly 20 minutes, users notice the machine within a week. Sample from a range, and occasionally break the pattern — a fast reply when she's meant to be busy reads as her sneaking a look at her phone, which is a nice character beat.
4. A cost side-effect worth noting
Characters who are asleep or head down generate no inference. Rough modelling on the coverage chart suggests roughly a third of hypothetical message volume is deferred or absorbed by shorter replies — and "at work" replies are genuinely shorter, so cheaper.
This doesn't change the ₹14.92 serving figure, which was already modelled at 40 messages/day. But it does mean the presence system is very unlikely to increase cost, and may modestly reduce it. A realism feature that pays for itself is rare.
5. Still open
Does status frustrate or deepen? The central unknown. Instrument it: compare retention and session counts for users whose primary character has a restrictive rhythm (Meera) versus a permissive one (Divya).
Time zones. Everything here assumes IST. A user in the Gulf or US messaging an India-based character creates real mismatch — worth deciding before any diaspora marketing.
Weekends and festivals. Ananya's Saturday should look nothing like her Tuesday, and Diwali should visibly change everyone's schedule. Not yet modelled.
Illness, leave, bad days. Occasional unscheduled absence — she's ill, phone died, family emergency — would add texture, but needs care so it never reads as the app being broken.