Group the requests
Collect every sender asking for this filter.
MOBIUS
Mobius sorts what users send
Mobius is the observatory of SylvieSI, a product of THE SHRIKS. It reads what users send from your app, Slack and Gmail, identifies the sender, groups duplicate reports and labels each message as a bug, a feature request, a question or feedback.
See how it groups messages ↓
InboxCustomersInsightsIdeas
What Mobius does, and what it does not
Mobius turns a stream of messages into something your team can act on. Every message arrives with its sender, its source and its original words. Mobius labels it, groups it with matching messages and shows how sure it is. Your team reviews the result: accept a label, link or unlink a duplicate, ask the sender for more information, or attach the message to an Idea or a Case.
Mobius never edits your product. No question goes out to a sender without a send confirmation, and every statement links back to its source.
Three messages, one bug
Mobius groups messages that describe the same bug and keeps every original. A person can split a group at any time.
In-app message
“The export downloaded twice.”
Reported in your app.
Slack message
“Got two copies of the export file too.”
Same bug, reported in Slack.
Email
“Exports have been duplicated since Tuesday.”
Same bug, reported by email.
One Case
Known: three senders, one bug. Open: the cause. Kept: every original message.
A different bug
Another sender reports two export emails, not two files.
The words are close, but this may be a separate bug.Mobius groups messages. A person can always undo a group.
Know who is writing
Mobius links each message to a sender, their account and the part of the product they used. Mobius is not a CRM. It holds no revenue fields, and every statement links to its source.
Example customer
- Who
- The person and company, and how the sender was identified.
- Where
- The page or feature they were using.
- Asked for
- Their bugs and requests so far.
- Usage
- Product usage, when you connect a usage source. Without one, Mobius shows that none is connected.
- Trust
- Signed in-app, verified by Slack or Gmail, or unverified. An unverified sender is never linked to an account automatically.
Where you work in Mobius
Mobius has an overview, an inbox, a Customers list, an insights page and an ideas list.
Overview
What changed since you last looked: new bugs, growing requests, conflicting requests and gaps in the data. Every line cites its source.
Inbox
Every message with its source, label and confidence. Filter by bugs, feature requests, questions, feedback or needs clarification.
Customers
Each sender’s messages, bugs and requests on one page, with tabs for messages, usage, cases, outcomes and a timeline.
Insights
Patterns across messages: an emerging bug, a growing request, a conflict between requests, a gap in the data.
Ideas
Feature requests gathered into an Idea, with the arguments for and against, a decision and a measured outcome.
What you can do with a message
Mark it reviewed. Accept or change its label. Link it to a duplicate, or unlink it. Attach it to an Idea or a Case. Ask the sender for more information. Dismiss it with a reason. Each action is saved in the audit history, and a link can always be undone.
Mobius asks when information is missing
The Triage agent drafts a question. A person, or your reply policy, sends it on the channel the message came from. The reply joins the original message. No question goes out without a send confirmation.
“Let us filter the table by our own fields.”
A feature request becomes an Idea before anyone builds anything.
Show both sides
Another sender may export to a spreadsheet instead. Mobius shows that next to the requests.
A person decides
Build it, defer it or hand it to engineering, with a reason.
Disagreement stays visible
“We need to filter by user and date.”
“We export to CSV and filter in a spreadsheet.”
Both belong in the Idea. A request that many senders repeat is not always one worth building.
From requests to a decision
An Idea shows who asked, how many, the objections and the options. A person saves the decision: already solved, ask for details, reject, defer, build a component for staging, or hand to engineering.
Collect the requests
Keep each sender’s words.
Weigh both sides
Show the arguments for and against.
Save the decision
Only Owner, Admin and Product roles can decide, and a decision needs at least one source.
Request access to the pilot
Tell us how your team handles bug reports and feature requests today.
Request access ↗