Skip to main content

​
Signals and in-app feedback

Signals capture what real usage reveals: bugs, friction, missing features, confusion, or data problems. They help you decide what to build next. Look for Signals (and Feedback) under the selected project. This page is the product surface for Usage-Driven Development: usage is evidence you review, not an automatic rewrite of the app. Prefer reading the Grouped tab over inventing the next feature from a vague feeling. Describe the outcome you want after you triage (for example: clients can download their statement as PDF). GenieForge maps that to the blueprint change. Preview as the role that felt the friction before you publish. Committed direction lives on Roadmap in the sidebar. Signals stay the usage inbox. Adding a cluster to the roadmap is a decision to build it, not the same as grouping reports.

​
Where signals come from

  • People submit Feedback in the product when something is wrong or missing.
  • The AI inside your app may record a signal when it must decline a missing capability or when something is clearly broken.
  • Usage can file a friction signal when a published page in navigation has not been opened while the rest of the workspace is busy. See Product usage.
Each item should carry enough context to reproduce the gap (what the user wanted, what failed, who was involved).

​
Email notifications

New apps turn Signal Email Notifications on by default under App Settings → Agent. When a signal is captured, you get an email with the type, severity, title, the signal ID, and a link that opens that report on the project’s Signals list. The ID also appears on each Signals card (click to copy). Turn the setting off if you prefer to check Signals only in the dashboard.

​
Grouped: similar reports together

On the Signals Grouped tab, related reports are clustered and ranked. Use Grouped when you want the living picture of what keeps happening; use the flat Signals list when you are inspecting a single report. When you decide a cluster is something you will build, use Add to roadmap. That creates a Later item on Roadmap. If it is already on the board, the row shows the horizon and links there.

​
App vs platform

Each group is tagged as: When a signal looks platform-related, GenieForge also files Platform Feedback automatically. Both entries stay visible. Closing one does not close the other, so a mistaken platform tag still surfaces for you to dismiss. Account or billing issues still go to support@genieforge.ai.

​
End-to-end example

  1. A client in the portal asks to download a PDF statement. That path does not exist yet.
  2. The agent declines and records a signal (or the client submits Feedback).
  3. Two similar reports land the same week; Grouped shows them as “PDF statement export.”
  4. You review the cluster, confirm it is an app fix, and add it to the Roadmap (or open Build with that context).
  5. You approve a plan so clients can download their own statement, Preview as client, and keep a version.
  6. You add a small eval for “client asks for statement” so the path does not quietly break later.
That is the UDD loop without inventing requirements in a vacuum.

​
What to do as a builder

  1. Triage Grouped weekly (or after a busy launch).
  2. Prefer the highest-ranked, well-evidenced clusters.
  3. Add the ones you commit to onto Roadmap. Fix in Build with a named plan; Preview as the roles in the signal.
  4. Dismiss or ignore noise; do not treat every signal as a ship commitment.
  5. For true platform gaps, track Platform Feedback and work around in-app until the platform catches up.

​
What can go wrong

  • Treating every signal as an immediate Build (burns credits; fragments the product)
  • Ignoring Grouped and only reading chat anecdotes
  • Mixing Signals clusters with the product Roadmap (one is evidence, the other is a commitment)
  • Closing Platform Feedback and assuming the app signal is gone (or the reverse)
  • Shipping a fix without Preview as the role that filed the friction