Customer support

Read every message, not just the loudest one

One period of what your customers wrote — in your tickets, in a CSV, or in a sheet — sorted into named themes and quoted word for word.

Join the waitlist See what it produces

Customer voice

Hear your customers

Who it is for: The support or CS lead who has the tickets and not the pattern inside them.
What starts it: Weekly on Monday in your workspace's time zone, and on demand from the catalog; On a schedule

Coming soonHear your customers is built, but not ready yet, so it cannot be turned on today. In Aestus you can ask to be told when it is ready.

The feedback you already have is the feedback nobody has read together. Each ticket was answered and closed, so nothing on the board looks wrong, and the thing forty people said in forty separate rooms is the one thing that was never written down. Reading it properly is slow, so it happens once a quarter, which is why the quarterly review is always about the complaint someone happened to remember.

This is the use case in the library most likely to lie to you, and the design starts there. "Customers are frustrated about onboarding" is a sentence a model will write from three messages and a hunch. It reads exactly like a finding. A team acts on it, and nothing about it can be checked, because there is nothing underneath it to check. So the model here is given the smaller half of the job: it proposes which messages belong together and quotes the line it read, and the shape it returns has no field to put a number in.

Everything that makes a theme a theme is then decided by arithmetic. Every quote is compared character for character against the message it cites, and a paraphrase is deleted. Every message reference has to be one this run actually read. The theme's size is counted in people rather than messages, because one person writing nine times is one person with a problem and three people writing once each is a pattern. And the server checks what those people's tickets actually share — the same label, the same linked ticket, or the same run of words two of them typed — and drops any theme that shares none of them. That last check is the reason this page is allowed to use the word "theme" at all, and every kept theme prints the shared thing in plain words, so you can open two tickets and disagree.

It does not score sentiment, and that absence is deliberate rather than missing. Nothing in Aestus records how a customer feels, so a tone grade would be the model's impression of its own reading, with nothing behind it. A theme named or defined by a feeling is refused by name. Their own words are quoted instead, which is both more useful and more checkable — and a customer who wrote that they were furious keeps that word, because it is theirs.

What it cannot hear, it says. There is no survey platform, no support desk and no review site connected, so there are no scores in the digest and nothing in it is a rating. A ticket on a team you cannot see is left out entirely and counted, which matters more here than almost anywhere else: a theme whose customers are partly hidden is reported smaller than it really is, and a theme that reads small is a theme somebody decides not to act on. So whenever anything was hidden, the digest says plainly that every count in it is a minimum.

The names are the quiet part that makes the rest worth having. Each run reuses last period's theme names whenever the definition still fits, so "Export is slow" in September is the same theme as "Export is slow" in October and the comparison means something. A name that comes back for a second period stops being last week's output and becomes a cited claim in Workspace Memory, sitting in the review queue with the ticket and the run it came from — so you can correct the wording, or retract a name you never liked, and the next run uses yours. A name seen only once is not recorded, because a theme that has not survived a second period is a thing that happened rather than a thing you have. What it deliberately does not carry across is a number: what survives from an older run is the model's raw answer, before that run's checks dropped what it could not prove, so a "26 down to 17" would be comparing a verified figure against an unverified one and looking more rigorous than either. "What changed" is a list of names, and every count on the page belongs to the period it was counted in.

What you get

The artifact this use case produces, in the product view you would read it in.

Example — fictional team and data. Not a live run or customer result.

Worked example

document

Customer voice — 7 to 14 September 2026

Produced by: Run EXAMPLE-HC-01 · project read-only · nothing filed · demo values

Scope: 11 messages read from 10 customers in this period, against 14 in the period before. 2 tickets were left out because they belong to teams this reader cannot see, so every count below is stated as a minimum — a theme whose customers are partly hidden is smaller on the page than it is in reality, and a theme that reads small is one somebody decides not to act on. A theme needs 3 different customers here.
Themes: 2 themes, most customers first, with Customers, Messages, Share of messages read, Shared evidence, First heard, Last heard and Seen last period. Customers comes BEFORE Messages deliberately: "Export is slow" is 4 people writing 5 messages, and a table led by the message count would rank the loud above the common. The share is written as 5 of 11, never as a percentage.
What customers said: One subsection per theme, and every quote in it was checked character for character against the message it cites. "Export is slow" is held together by the label export, carried by the tickets of 3 of its customers; "Invite emails land in spam" by 3 of its customers typing the words "invites went to spam". Both are computed from the tickets rather than asserted by the model, and both are printed so you can open two tickets and disagree. Under each sit the verbatim lines — "I hit export on the board and nothing happens for two minutes, so I hit it again and got two files." — with their message ref and every customer's ticket as a link.
What changed: Names only: 1 of the 2 themes are new this period and the rest this workspace already had a name for, so "Export is slow" means the same thing it meant last month. No previous number appears here, deliberately — what survives from an older run is the model's raw answer, before that run's checks dropped what it could not prove, so a comparison against it would look more rigorous than either figure alone and be less.
Not themed: 3 messages joined no theme, and the section names them rather than letting them disappear. One of them was in a theme the model proposed and the server refused: 2 distinct customers across 2 messages, bar is 3. A run that only reports what it found reads as complete; this one states what it dropped and the rule that dropped it.
What this did not hear: The blind spot, in the digest itself, never softened: no survey platform, no support desk and no review-site feed is connected, so there is no CSAT, NPS or CES score anywhere in this document and nothing in it is a rating. The words are the messages written by the person who opened each ticket, so a reply from your own team is not in it. No theme is named or defined by how a customer feels — their own words are quoted instead, furious ones included.

How it runs

Each step is one node in the workflow graph the interpreter runs. Nothing here is a prompt chain hidden in a route handler.

Workflow steps

01It reads what the customer wrote
One source per run, whichever you pick: the messages the person who opened each ticket wrote on the Aestus project you name, the newest CSV your team attached to the review ticket, or one range of one Google Sheet read through your own connection. A file or a sheet needs three columns — a response id, a date, and the comment — and the run tells you which column it could not find instead of guessing. There is no survey platform and no support desk connected to any of them, so there are no scores in this anywhere.
02A model proposes the themes, and nothing else
It suggests which messages belong together and quotes the line it read. It never says why they belong together, and the shape it returns has no field to write a number in.
03The bar is counted in customers, never in messages
One person writing nine times is one person with a problem. A theme needs at least three different people, and you can raise that but not lower it.
04The server checks what those customers actually share
A theme is kept only when its tickets share something you can go and look at: the same label, the same linked ticket, or the same run of words two people typed. A theme with none of those is dropped, whatever was written about it.
05It quotes them, and the quotes are real
Every quote is checked character for character against the message it cites. A paraphrase, a joined fragment or an added ellipsis is deleted, and a theme whose quotes are all deleted goes with them.
06It publishes, and says what it missed
The digest lands as a document on the period's ticket, and names what it dropped, who it could not read, and what it cannot hear at all. The Slack post waits for a person to approve it.

By hand, and on Aestus

The same job, on either side.

By hand
Someone skims the week's tickets and remembers the loud ones.
On Aestus
Every message is read and grouped, and the count that decides a theme is people, not messages.
By hand
Two customers sound alike, so you treat them as one thing.
On Aestus
A theme is kept only when its tickets share a label, a linked ticket, or the same words — and the digest prints which, so you can disagree.
By hand
Quotes get tidied up on the way into the deck.
On Aestus
Every quote is checked word for word against the message, and a tidied one is deleted before you see it.
By hand
New theme names every month, so nothing can be compared.
On Aestus
Last period's names are recalled and reused when the definition still fits, and the digest says which are new.
By hand
"A lot of people are unhappy about this."
On Aestus
A count of the tickets listed under that theme, with every one of them linked on the same page.
By hand
Nobody says what was left out.
On Aestus
The digest names the messages that joined no theme, the themes it refused and why, and the tickets it was not allowed to read.

What Aestus records

Every run is auditable after the fact, which is what makes handing the job over survivable.

The run
Cost, tokens, duration and whether the check passed, on the same ledger as every other run in the workspace.
The digest
Each period's digest is an artifact on that period's ticket, with its own revision history, so last month's can still be reopened.
The vocabulary
A theme name that has come back for a second period is recorded in Workspace Memory as a cited claim you can read, edit or retract — and the next run reuses your wording, not the model's.
What it refused
Every theme it dropped and the rule that dropped it, so a missing theme has a reason rather than a silence.

What it connects to

Only the tools this workflow actually uses. Each one has a setup guide.

slackOptional

Questions teams ask

Does this read my CSAT or NPS survey?

No, and it never reports one. There is no survey platform, no support desk and no review-site feed connected to Aestus, so this digest contains no CSAT, NPS or CES score and nothing in it is a rating. What it reads is what people wrote: your Aestus tickets, a CSV you attach, or a Google Sheet. If your survey tool can export a sheet or a file, this can read the comments in it — but it reads the comments, never the scores beside them.

Where do the words come from, and whose are they?

One source per run, out of three. Your Aestus tickets by default, and there the customer is the person who opened the ticket — resolved as whoever wrote the first message in its room — so replies from your own team are never read. Or the newest CSV or TSV file on the ticket this digest is filed against. Or one range of one Google Sheet, read through the Google connection of whoever the automation runs as, so it sees only what that person can already open. A file or a sheet needs a response id, a date written year-first, and the comment itself; an email column is never used as the id, because the id is printed beside every quote. An address or a phone number inside a comment is replaced before anything reads it, the model included.

Will it tell me how customers feel?

No. Nothing in Aestus records how anybody feels, so a tone score would be the model's impression of its own reading, with nothing for you to check it against. A theme named or defined by a feeling is dropped by name. Your customers' own words are quoted instead, including the angry ones.

What stops one loud account becoming a theme?

The bar is counted in people, not messages. Nine messages from one respondent is one customer. A theme needs at least three different customers, and the digest prints both numbers so you can see the difference.

Can it invent a number?

There is no field for a number in what the model returns. Every figure is counted afterwards from the message list the run was given, and each count equals the number of links printed for that theme. Previous periods carry no numbers forward either, only names.

All use cases How access is governed

Sources

Thematic analysis — label each item, group the labels, name the group, then count and quote it. https://en.wikipedia.org/wiki/Thematic_analysis (read 2026-09-12)
Nielsen Norman Group, Thematic Analysis of Qualitative User Research Data. https://www.nngroup.com/articles/thematic-analysis/ (read 2026-09-12)
Inter-rater reliability — why a code applied by one reader, unchecked, is not yet a finding. https://en.wikipedia.org/wiki/Inter-rater_reliability (read 2026-09-12)

Hand over Hear your customers.

Tell us how your team does this today and we will set it up with you.

Talk to us

Hear your customers

Who it is for

The support or CS lead who has the tickets and not the pattern inside them.

What starts it

Weekly on Monday in your workspace's time zone, and on demand from the catalog

On a schedule

Coming soonHear your customers is built, but not ready yet, so it cannot be turned on today. In Aestus you can ask to be told when it is ready.

Customer voice — 7 to 14 September 2026

Produced by: Run EXAMPLE-HC-01 · project read-only · nothing filed · demo values

Scope: 11 messages read from 10 customers in this period, against 14 in the period before. 2 tickets were left out because they belong to teams this reader cannot see, so every count below is stated as a minimum — a theme whose customers are partly hidden is smaller on the page than it is in reality, and a theme that reads small is one somebody decides not to act on. A theme needs 3 different customers here.
Themes: 2 themes, most customers first, with Customers, Messages, Share of messages read, Shared evidence, First heard, Last heard and Seen last period. Customers comes BEFORE Messages deliberately: "Export is slow" is 4 people writing 5 messages, and a table led by the message count would rank the loud above the common. The share is written as 5 of 11, never as a percentage.
What customers said: One subsection per theme, and every quote in it was checked character for character against the message it cites. "Export is slow" is held together by the label export, carried by the tickets of 3 of its customers; "Invite emails land in spam" by 3 of its customers typing the words "invites went to spam". Both are computed from the tickets rather than asserted by the model, and both are printed so you can open two tickets and disagree. Under each sit the verbatim lines — "I hit export on the board and nothing happens for two minutes, so I hit it again and got two files." — with their message ref and every customer's ticket as a link.
What changed: Names only: 1 of the 2 themes are new this period and the rest this workspace already had a name for, so "Export is slow" means the same thing it meant last month. No previous number appears here, deliberately — what survives from an older run is the model's raw answer, before that run's checks dropped what it could not prove, so a comparison against it would look more rigorous than either figure alone and be less.
Not themed: 3 messages joined no theme, and the section names them rather than letting them disappear. One of them was in a theme the model proposed and the server refused: 2 distinct customers across 2 messages, bar is 3. A run that only reports what it found reads as complete; this one states what it dropped and the rule that dropped it.
What this did not hear: The blind spot, in the digest itself, never softened: no survey platform, no support desk and no review-site feed is connected, so there is no CSAT, NPS or CES score anywhere in this document and nothing in it is a rating. The words are the messages written by the person who opened each ticket, so a reply from your own team is not in it. No theme is named or defined by how a customer feels — their own words are quoted instead, furious ones included.

Questions teams ask

Does this read my CSAT or NPS survey?

Where do the words come from, and whose are they?

Will it tell me how customers feel?

What stops one loud account becoming a theme?

Can it invent a number?

Sources

Thematic analysis — label each item, group the labels, name the group, then count and quote it. https://en.wikipedia.org/wiki/Thematic_analysis (read 2026-09-12)

Nielsen Norman Group, Thematic Analysis of Qualitative User Research Data. https://www.nngroup.com/articles/thematic-analysis/ (read 2026-09-12)

Inter-rater reliability — why a code applied by one reader, unchecked, is not yet a finding. https://en.wikipedia.org/wiki/Inter-rater_reliability (read 2026-09-12)

Read every message, not just the loudest one

Hear your customers

What you get

Customer voice — 7 to 14 September 2026

How it runs

By hand, and on Aestus

What Aestus records

The run

The digest

The vocabulary

What it refused

What it connects to

Questions teams ask

Other use cases

Hand over Hear your customers.

Read every message, not just the loudest one

Hear your customers

What you get

Customer voice — 7 to 14 September 2026

How it runs

By hand, and on Aestus

What Aestus records

The run

The digest

The vocabulary

What it refused

What it connects to

Questions teams ask

Other use cases

Hand over Hear your customers.