Use casesCustomer Support
Support that already knows the account.
Your agents and your bots read the same history: every ticket, call and email about a customer, resolved onto one record and dated.
Priya wrote in again about the CSV export failing. She moved up from Starter to Growth on 2 June, so this is covered.
- Account plan is Growth, since 2 JuneReplaces the earlier value
Starterkept, dated - CSV export failing
- Third export issue this quarter
What plan is Priya on, and has she raised this before?
Growth since 2 June. This is her third export issue this quarter, and the first two are linked as evidence.
The problem
Why support still asks the question the customer already answered
01
Four systems, four identifiers
Tickets, calls, email and billing never join, so the assistant answers from one fragment and asks the customer to re-explain the rest.
02
Confidently quoting the plan they left
Pre-upgrade tickets stay in the store unmarked. Quote the wrong entitlement and you have made a promise, not an error.
03
The pattern nobody sees until it churns
The third failed export is a different conversation from the first, but only if something is counting. Ticket by ticket, nothing is.
What memory changes
One record per customer, current and sourced
01
One customer, however they appear
An email address, a name in a transcript and a chat handle resolve onto one node as evidence accumulates.
02
Current value, dated history
A plan changed in June has one current value and a history. Ask what it was and the old plan is still there.
03
Answers that cite the ticket
POST /answer returns the evidence behind the answer, so an agent can check the source before repeating it to the customer.
Economics
The bill does not grow with the history.
The usual alternative is to send the whole record to the model on every question, so cost climbs with every message you have ever stored. We read a roughly fixed amount per question whether the record holds a hundred thousand tokens or ten million.
- 23x cheaper per question than sending 1M tokens of history, on the same model
- 232x cheaper at 10M tokens, where no production model can hold the context at all
- Around 96% less context read per question at 1M tokens of history
Integration
Three calls, and nothing to host.
One input shape: text plus a timestamp. You do not pick an embedding model, chunk anything, maintain entity tables or write prompts that decide which of two conflicting statements is current.
- Four endpoints and one bearer token, called directly over HTTP
- Ingestion is idempotent by content hash, so a crashed backfill just re-runs
- SOC 2 Type II, ISO 27001 and ISO 27701, with the API inside that same scope
Why Revo Memory
Why support teams pick Revo Memory
Organization scoped, not user scoped
The same customer handled by three of your agents is one relationship with three sources, not three separate memories.
Backdatable timestamps
Load years of ticket history and it lands on its real dates, so the history reads correctly from day one.
Permissioned retrieval
Content carries an audience and the filter applies during the search, so restricted material is never loaded into an answer.
Deletion that actually deletes
Removing a source removes the facts derived from it and the sentences that produced them.
Flat cost per question
A five year old account costs about the same to query as a five day old one.
Works for bots and humans
The same four endpoints serve an agent-facing assistant and the console your support team already uses.
More use cases
The same engine, other shapes of work.
Tell us what you are building.
Keys are issued by hand while the API is in early access. Bring your volumes and the shape of your integration, and we will tell you straight whether it fits yet.