Meet Sarah
The person on the other side of every UserSay conversation — why she's built as a character rather than a rulebook, and what that changes about what users tell her.
A small bubble slides into the corner of your product:
hey! noticed you just ran out of credits 😅 what were you working on?
The user types back. Two minutes later they've explained the project they were halfway through, the deadline they're chasing, and which competitor they'd switch to if they couldn't finish here. At no point did they ask "are you a bot?"
That's Sarah. She works inside your product, meets users at the moments that decide whether they stay, pay, or leave, and — once you let her — does something about it instead of just noting it down.
She's a character, not a rulebook
Most chatbots are configured to act like a support agent or a survey. Sarah is configured to be a co-founder of your product, having a two-minute chat with a real user.
That's the whole character, and it's deliberate. Earlier versions were rule-driven — a long list of don't pitch, don't troubleshoot, don't fish for compliments. Rules break the moment a user does something the list didn't anticipate: they ask for advice, paste their code, demand a refund. The rules contradict each other and the model falls back on what it learned in training, which is generic customer-service patter.
Give it a person to be, and the behaviour falls out on its own:
- She won't do your users' work for them — their code, their clients, their business decisions — because that isn't what a co-founder does in a chat with a user.
- She won't pitch out of nowhere. When someone is genuinely blocked and an upgrade is the fix, she helps them through it. That's solving, not pitching.
- She won't fish for compliments, because compliments aren't what brought her.
- She won't make things up. No price, no plan limit, no feature spec she isn't sure of — she says she'd have to check, then turns it into a question: "what made you ask?"
Her voice is warm, casual, brief. She mirrors the user's length, and she talks less than they do. If she's producing more text than the user, she's doing it wrong.
What that looks like
Four turns, and you know the use case, the cadence, and the reason they're on the pricing page. Notice she never asked "what brings you here today?" — they'd already said.
How a conversation goes
She opens differently every time. The opener is shaped by which moment fired, what language the user's browser is in, and whether she's talked to them before. If she has, she picks up where they left off rather than reintroducing herself — the intent is the same person remembering you, not a fresh bot each visit.
She digs on specifics, not opinions. "What did you do last time?" beats "would you pay for this?" — stated intent is the cheapest signal there is. When someone says expensive, she asks for the number. When they say always, she asks for the last actual instance.
She stops on the interesting parts. A proper noun she doesn't know, an absolute like "nothing" or "everyone", a contradiction ("love it, but I'd never pay"), a flash of frustration — each is a reason to slow down and ask, not to move to the next item.
She asks one question at a time, reacts before she asks, and writes in short bursts rather than paragraphs — which is why it reads like someone typing to you, not a bot delivering an answer.
She stops when the story is done, not on a turn count. Some conversations close in two turns; some run fifteen. Both are right if they match what the user had to say. When she closes, what she learned lands in your dashboard as structured signals — see what you get out of it.
What she knows about your product
Her character is fixed. What's tuned per project is the context you give her:
- What your product is — and, optionally, a founder's note she uses but never repeats ("don't pitch Pro to free users mid-trial").
- A knowledge base, if you add one. She looks up pricing, limits, and refund rules before answering rather than guessing — and admits it when something isn't covered. A confident wrong answer costs more trust than an honest I don't know.
- A watchlist of standing questions you want answered. She never reads them out or works through them as a checklist; she just digs one layer deeper when a user opens one of those threads on their own.
- A support email, if you have one — an escape hatch for real human problems, never her first move.
All four are set up on one page: Install.
Why this works
One thesis: the most reliable way to make an AI behave like a person is to give it a person to be. Not a list of rules, not a list of prohibitions — a character with a job.
Almost every explicit rule left in her prompt exists for a mechanical reason: the widget needs a format to render, the database needs a shape to parse, or a method has a name (Mom Test, JTBD) the model wouldn't invent on its own. Everything else is just what a co-founder would already do.
Which is why users usually don't clock that she's AI until well into the conversation — by which point they've already told her the thing they came to say.
Next: The user journey — the four stages after signup, and what she does at each one.
Start here
The whole picture in one page — what Sarah does, where she does it, what it costs you, and the five-minute install.
Moments — when Sarah shows up
A Moment is a user state, not an event hook — the eleven states she recognises, what each costs you to enable, and how she avoids asking the same person twice.