Missing answers repeat
A question your knowledge does not cover fails for the next person who asks, and the one after. Finding them today means reading transcripts by hand.
Improve
Your users already told you what to fix and what to build.
Your team gets the questions your assistant could not answer, with answers ready to pick, and a list of what people asked your app to do, counted by the people who asked. Rendel is the AI assistant inside your mobile app and website: it answers from each customer's own account and gets tasks done through your API, each change confirmed with a tap or undone with one.
Halden’s console, an invented store with Rendel running. Yours for two hours, no sign-up.
To do
Questions to answer
asked 9 times · 7 peopleSaid it could not
Do you deliver on Saturdays?
Which answer is right for Halden?
1Not yet: deliveries run Monday to Friday, usually within 2 to 4 working days.SuggestedFrom your source “Shipping and delivery”
2Yes, in Amsterdam and Istanbul: orders placed by Friday noon can arrive on Saturday.
Rendel will learn
Saturday delivery
Not yet: deliveries run Monday to Friday, usually within 2 to 4 working days.
Add to Knowledge
Requests to build
Pick up in a studio
Open31 people in 30 daysRisingasked 40 times
How they asked
- “click and collect?”Open conversation
- “Siparişimi mağazadan alabilir miyim?”Open conversation
The problem
Your assistant hears what people want. Today, your team does not.
People ask the assistant in your app for a delivery day, a warranty, a way to pay in parts. When it has no answer, or the app cannot do it, the moment ends there: the same question fails for the next person, and the request never reaches whoever decides what to build.
Requests disappear
“Can I pay in installments?” gets a polite no, and then it is gone. Nothing counts how many people asked, or keeps how they put it.
Nobody hears when it ships
When you do build it, the people who asked are not told unless someone finds each of them and writes.
Or a stack of separate tools
A feedback board, a feedback-analytics tool with its connectors, a report on what one support bot missed, and a changelog to announce it. Each needs its own setup, and each learns of a request only after someone writes it down.
How it works
From a question it could not answer to an answer for the next person.
What Rendel could not answer comes back to you with answers ready to pick, and what people asked your app to do comes back counted, in their own words.
Someone asks, in their own words
A shopper asks something Rendel has nothing of yours to answer from, or asks the app to do something it cannot do yet. Rendel tells them so, and notes it for your team.
Rendel turns it into one plain question
A job that runs every ten minutes joins the ways people asked into one card, with how many times and how many people, and prepares answers to pick from your own knowledge.
You pick one, or write a few words
The likely answer is marked. Pick it, or type your own in a few words, then add it to Knowledge with one tap.
The next person who asks can get the answer
The answer is written into Knowledge and indexed, so the assistant can answer from it when someone asks again.
Requests are counted, and the people who asked can be told
What people asked the app to do is grouped one request per row and counted by people. Mark it Shipped, and with Follow-ups on, they hear it is here, in your app or by push.
Questions to answer
Teach it once, and the next person who asks can get the answer.
The questions Rendel answered with nothing of yours behind it, said it could not answer, or got a thumbs-down on come to one list, sorted into plain questions with answers ready to pick.
Answers ready to pick, the likely one marked
Each card comes with two to four answers drawn from your own knowledge and persona. The one Rendel thinks is right is marked, and each says which of your sources it rests on, or that it is a guess to confirm. Preparing them is not counted as messages; it pauses only once this month's messages are used.
- Not counted as messages
- Pick with keys 1 to 4
Type a few words, and Rendel writes it up with blanks, not guesses
Type the answer the way you would say it. Rendel turns it into a knowledge source, is told to add no fact you did not give, and leaves ____ where a step is missing. Edit it before you add it; writing it up does not count as messages.
One tap, and it is in Knowledge
The next person who asks can get it. The answer goes into Knowledge as a source and is indexed, and the card moves to Done this visit, with Open it to read the new source.
The questions it missed, in one list instead of in transcripts
Most asked first, each with how many times and how many people asked it, and a running count of what is done. You open a conversation only when you want to.
- 7, 30 or 90 days
- Live or Test key
Many ways of asking, one card to answer
Answer once for every way it was asked. Wordings of the same question are sorted onto one card under one plain question, each linking to its conversation; one not sorted yet waits on its own card, in quotes, until the next run.
What you answered or put away stays away
Skip a card for later, or put it away as not something you answer, and bring it back while you are still on the page. Decisions are kept per wording, so a new way of asking comes back. Questions knowledge cannot fix, such as requests to do something, small talk and tests, are set aside with one button to clear them.
Opens on the right question from elsewhere in the console
Home, Knowledge and a person's page link straight to the matching question or request, so you land on the exact card.
Or ask the console's own assistant what to fix
Inside the console, ask Rendel what needs your attention. It reads both lists, and can add an answer to Knowledge after you confirm a card that shows the whole text. It is on by default, and off by default for regulated organizations.
Requests to build
Know what to build next, from the people who asked for it.
When someone asks your app to do something it cannot do yet, Rendel writes down what they wanted. Requests are grouped one per row, counted by people, and kept in their own words, so you build on evidence instead of guesses.
Know what people wanted when your app could not do it
Each time Rendel tells someone it cannot do something here, it is told to note what they wanted, so a polite no still reaches your team.
One row per request, across wordings and languages
“click and collect?”, “Siparişimi mağazadan alabilir miyim?” and “pick up instead of delivery” land on one row, with how many different people asked and how many times. A request is named in English whatever language people used. On your live key a row is listed once 3 different people have asked; the Test key shows everything.
Read the need in their words, not a summary
Each request shows how people actually asked, with Open conversation beside each quote. A role that may not read transcripts sees short phrases instead.
How they were turned away, and why building it helps
Two short lines on each request: what Rendel told them, and the benefit of building it. They are written under a rule never to name or describe a person. Writing them is not counted as messages. Once this month's messages are used, new lines are not written, and the card shows the rest.
A list that orders itself by demand, with your status on it
The most-wanted request sits at the top: rows are sorted by people, then times asked, and marked New, Rising or Falling. Set Planned, Shipped or Not planned as you decide; shipped and out-of-scope rows fold away, and every status change is in the audit log.
An estimated value on each request
Each request you could build shows roughly what it would avoid in support contacts once people can do it in the app, from your own numbers in Settings › Value or a cited industry average. Where an input is missing, it shows no figure rather than an invented one.
Would you rather not build it yourselves? A request can be built for you at a fixed price, shown on its card before you approve, and nothing is charged until a person confirms the size.
After you act
Tell the people who asked, and fix what keeps failing.
Answering a question or shipping a request can reach exactly the people who asked. Below the requests, the actions that fail are listed in plain words, with where to look.
Ship it, and the people who asked hear it is here
With Follow-ups on, marking a request Shipped tells each person who asked, and answering a question tells the people who asked it. Each gets one message for it, in your app or by push, and it also waits as a card at the top of Rendel. If “Asked-for feature shipped” is off, Engage suggests it once three people are waiting.
- Off until you turn it on
- In the app: Flutter 0.59.0 · Web 0.38.0
- Card in Rendel: Flutter 0.59.7 · Web 0.38.7
Only real faults, in plain words, with where to look
Errors from your API, timeouts and bugs are grouped by action and error, most frequent first. Calls that failed because nobody was signed in, the conversation moved on, or your own rule said no are the app working, and fold away. An endpoint connected in the console opens straight to its settings.
Compared
What one console ties together that separate tools cannot.
A feedback board learns of a request when someone files it. Rendel hears it when someone tries to do it, in your app.
| What | Rendel's Improve | A separate feedback tool |
|---|---|---|
| Where requests come from | What people asked your app to do, in your app, in their own words, as they tried | Votes, forms, tickets and calls that someone files, imports or connects |
| Questions your assistant could not answer | One card per question, with answers ready to pick from your own knowledge, added to Knowledge in a tap | Not seen by a feedback board; a support bot's own report covers only that bot |
| How demand is counted | Different people who asked, and how many times; listed once 3 people asked on the live key | Votes, or mentions matched to contacts |
| What stands behind a request | How each person put it, word for word, with the conversation one tap away for roles that may read it | A summary, a vote, or a link to a ticket |
| Tasks that fail | Real faults only, grouped by action and error, in plain words, with where to look | Not seen, or raw errors in a developer tool |
| Telling people it shipped | The people who asked, in your app or by push, once you mark it Shipped with Follow-ups on | Changelog subscribers, or a segment you build |
| Setup and price | Nothing more to install; it runs on the conversations Rendel already has, on every plan | Another widget, portal or connectors, usually with seats |
| Where the separate tool is stronger | Only what is said to Rendel; no public board, voting or issue-tracker sync | Every channel (reviews, calls, surveys), public voting, roadmaps, issue-tracker sync |
Keep the board you have for reviews, calls and surveys. Rendel adds what people asked inside your app, in their words.
Rendel next to other toolsControls and privacy
Your team decides who reads what, and nothing goes out until you turn it on.
Each role sees what its job needs. People's own words stay with the roles that may read conversations, and the people who asked choose how they hear from you.
Who on your team can do what
| What | Owner | Admin | Developer | Conversation reviewer | Analyst | Customer support |
|---|---|---|---|---|---|---|
| See Questions to answer | Yes | Yes | Yes | Yes | No | No |
| Pick, write or put away an answer | Yes | Yes | Yes | No | No | No |
| See requests: names, counts, trend, the two lines | Yes | Yes | Yes | Yes | Yes | No |
| See people's own words and open the conversation | Yes | Yes | Yes | Yes | No | No |
| Set a request's status | Yes | Yes | Yes | No | No | No |
| See failing actions | Yes | Yes | Yes | Yes | Yes | No |
| Approve and pay for a request to be built | Yes | Yes | No | No | No | No |
Analysts see request names and counts, never transcripts. Customer support sees only Support.
Their words stay with the people allowed to read them
Quotes and Open conversation show only for roles that may read transcripts. A question's link in the console carries a short code, never the words.
Written so it is not about one person
Rendel names each request in a few generic words, under a rule never to use a name, a number or anything about the person who asked. The two lines on a request and the prepared answers follow the same rule.
Some requests are left out by rule
Rendel is told not to note as a request something it turned down for privacy, safety or your own rules, such as another person's data or skipping a confirmation.
Kept only as long as the conversation
Each ask is tied to its message, so counts and quotes fade as conversations pass your retention window: 365 days by default, and you can set it. Erasing a person removes their asks with their conversations.
Where it is processed
Stored in Frankfurt (AWS eu-central-1). Emails, phone numbers and card numbers that users type are masked before the model sees them. The model provider does not use this traffic for training.
What the people who asked can turn off
Each person can opt out per channel. They get at most 1 follow-up a day and 3 a week, and none between 21:00 and 09:00 except in the app.
What Rendel does not do here
- Add an answer to Knowledge without someone on your team picking, writing or confirming it.
- Send a follow-up while Follow-ups are off. They are off until you turn them on.
- Move a request up or down because of anything sold. The list orders by people asking.
- Change a status without leaving it in your audit log.
In the demo console
Halden's week on To do, start to finish.
Halden is an invented shoe store with Rendel running for five weeks. Its console is yours for two hours, no sign-up. Here is one pass through it; the counts differ in every copy.
Open Questions to answer
Two questions wait for Halden's team. The first: “Do you deliver on Saturdays?”, asked in several ways.
Pick the answer the shipping article supports
Two answers are ready. One is a guess; the other comes from Halden's own “Shipping and delivery” article. Press 2, check what Rendel will learn, and add it to Knowledge.
Ask it yourself on Test
Open Test and ask “Can my order arrive on a Saturday?”. The answer now comes from the source you just added.
See what shoppers asked the app to do
On Requests to build: Pick up in a studio and Student discount are open, Pay in installments is planned. Open one to read how people asked, what Rendel told them, why it would help, and its estimated value.
Check what failed
Under the requests: the parcel-tracking endpoint sometimes times out. Signed-out calls are folded away, because that is the app working.
See who was told
Back-in-stock alerts shipped five days ago in Halden's story, and the people who asked were told. Gift wrap and Germany shipping were answered, and their askers heard too.
Try it in the demo console
Answer Halden's open questions, read its requests and see who was told. It opens on Questions to answer; Requests to build is one click away in the menu.
Getting started
Nothing to switch on for the two lists.
Questions to answer and Requests to build fill as soon as your app has conversations on the key you are looking at. Before the first one, each page shows what will land there.
Any current Mobile and Web SDK. The signals are written on the server by the conversation itself, so there is nothing to add to your app.
- Current: Flutter 0.82.0 · Web 0.57.0
Every plan, Pilot to Enterprise, with no add-on. Preparing answers and writing the lines on each request are not counted as your plan's messages; they pause only once the month's messages are used.
- Every plan
Try it on the Test key first: ask Rendel for something your app cannot do, like paying in installments, and it lands on Requests to build.
- Test key shows everything
Optional: put your own support numbers in Settings › Value, so the estimated value on each request uses them. Until then it uses a cited industry average.
- Owners and Admins
To tell people: turn Follow-ups on in Engage › Automations. “Answer arrived” and “Asked-for feature shipped” are on once you do. Push needs your Apple .p8 or Firebase key in the console.
- In the app: Flutter 0.59.0 · Web 0.38.0
- Card in Rendel: Flutter 0.59.7 · Web 0.38.7
Then make it a habit. The Go live checklist suggests opening both lists every week.
- Weekly
What teams ask before they start.
From the conversations people have with Rendel inside your app or website. Nobody fills in a form, votes or files a ticket. Rendel only hears what is said to Rendel: app-store reviews, calls and other help desks are not read.
One Rendel answered with nothing of yours behind it, said it could not answer, or got a thumbs-down on. A turn where one of your actions ran, an answer that opened a screen of your app, and small talk are not. Something people asked the app to do goes to Requests to build instead.
Rendel prepares two to four answers from your knowledge and persona and marks the one it thinks is right. Each says which of your sources it rests on, or that it is a guess to confirm. Nothing is added to Knowledge until someone on your team picks or writes one.
The console writes it into Knowledge as a source and indexes it, and the question leaves the list. From then on the assistant can answer from it when someone asks again. What you answered or put away does not come back; a new way of asking can.
No messages are counted for it: not for sorting questions, the answers to pick from, the two lines on each request, or writing up an answer you typed. Once this month's messages are used, though, nothing new is prepared, and you write answers yourself.
Three different people on your live key. Fewer shows only as a count under the list. The Test key lists everything, so you can try it yourself. A person is counted by their signed-in account, or by device when nobody is signed in.
One row. Requests are grouped by what was asked, across wordings and languages, and named in English. How each person put it stays in their own words, with the conversation one tap away.
Yes, with Follow-ups on in Engage; they are off until you turn them on. Mark the request Shipped once it is live, and each person who asked is told in your app or by push, within their caps and quiet hours. Answering a question can tell the people who asked it too.
Only real faults: an error from your API, a timeout or a bug, grouped by action and error, most frequent first. A call that needed a signed-in user, one the conversation moved on from, or your own rule saying no is the app working, and is folded under the list.
Owners, Admins, Developers and Conversation reviewers see people's own words and can open each conversation. Analysts see request names and counts only, and Customer support sees only Support. Data is stored in Frankfurt, and emails, phone numbers and card numbers that users type are masked before the model sees them.
No. There is no public board, voting or issue-tracker sync here, so keep the tools you have. Rendel adds what people asked while they were using your app, in their own words, with how many asked.
No. Both lists fill from conversations on any current Mobile and Web SDK, on every plan, with nothing to switch on. Telling people afterwards needs Follow-ups on, and messages in your app need Flutter 0.59.0 or Web 0.38.0 or later.
Related
- AnswersTheir own data, shown as your app’s cards instead of a paragraph.
- ActionsTasks done through your API, confirmed with a tap or undone with one.
- EngageMessages people asked for, written for you and sent with one tap.
- AnalyticsWhat people did, what they asked, and what got solved.
- Human supportYour team answers inside the app, with the conversation in hand.
- Setup by your agentYour coding agent adds it and fills in the console.
- How Rendel answers and acts
- Security and privacy
- Plans and messages
- Rendel next to other tools
Put it in your app this week.
Start free on your own, or tell us what your customers do most and we’ll show you that exact workflow, working, in a tailored demo.
- PilotFree400 messages a month
- Starter$199 / month4,000 messages a month
- Growth$799 / month20,000 messages a month
Prefer email?
sales@rendel.aiPrefer to write first?
Tell us about your app and we’ll show the right workflow in a tailored demo.