Sprout

Getting started

Sprout collects in-app feedback from your websites. You drop a small script onto a site, and a floating button lets visitors report a bug or share an idea — with a screenshot and the page details attached automatically. Everything lands on a board here, where your team triages it, comments, and marks it resolved.

  1. 1Create a project for the website you want feedback from, and add the origins it’s allowed to submit from.
  2. 2Install the widget by pasting one <script> tag into that site (copy it from the project’s Settings → Install).
  3. 3Watch feedback arrive on the project’s board. Drag cards between columns as you work them.
  4. 4Optionally, wire up automations (Slack, webhooks), connect a Slack workspace, or let a coding agent triage the board for you.

Projects

A project is one website’s feedback. It scopes everything — the board, automations, and the widget snippet all belong to a project. Create one per site from the Projects page.

Two settings matter most when you create a project:

Allowed origins
The only origins whose widget may submit feedback, one per line — e.g. https://acme.com. You can wildcard the left-most label only: https://*.acme.com matches app.acme.com but not acme.com or a deeper subdomain. A submission from an origin not on this list is rejected.
Project key (apiKey)
A public key baked into the widget snippet. It identifies the project on every submission; it only grants ingest, and is safe to ship in your site’s HTML. You can rotate it from Settings (the old snippet then stops working).
Archiving a project hides it and stops it accepting new feedback, without deleting anything. Restore it later from the global Settings page.

The feedback board

Each project has a board with four columns. Drag a card from one to the next as you work it — moving a card can trigger automations.

New
Just submitted, not yet triaged.
Backlog
Acknowledged, but not being worked right now.
In progress
Someone’s actively on it.
Resolved
Done — fix shipped or idea handled.

Open any card to see the full submission:

  • The description the user wrote, and any screenshots they attached.
  • Who sent it. A Guest tag means they signed in with just a name and email (self-asserted); staff submissions are verified.
  • The page URL, browser, and screen size — captured automatically so you can reproduce the issue.
  • An internal comment thread for your team (and for agents). Comments are private to the dashboard, never shown to the submitter.

The Copy button on a card exports everything as Markdown — with image links — so you can hand it straight to a coding agent.

The feedback widget

The widget is the floating button visitors use to send feedback. It runs in an isolated shadow DOM, so it never clashes with your site’s styles. Install it with a single tag in the page <head> (or anywhere before </body>):

index.html
<script src="https://sprout.mojoactive.io/embed.js"
        data-project="YOUR_PROJECT_KEY"></script>

That’s the whole install — one tag. Replace YOUR_PROJECT_KEY with the project key from Settings → Install (that page has a copy button). You paste this once and never edit it again: how the button looks and behaves — its corner, visibility, sign-in options, and branding — is all controlled from Widget settings in the dashboard, and changes take effect live.

Sending feedback

Anyone submitting first identifies themselves — this keeps junk out and tells you who reported what. Two ways, and you choose which to offer (see Widget settings):

  • Continue as guest — enter a name and email. No account needed; the submission is tagged as a guest.
  • Log in with account — staff sign in with their MoJo (Microsoft) account in a popup, and their identity is verified.

Once identified, the submitter can attach up to six screenshots:

  • Region — drag a box around part of the page.
  • Full page — capture the whole screen.
  • Upload — pick an image from their device (best on mobile).
  • Each screenshot can be annotated — draw on it to point things out.
Important: the button is hidden by default

By default the button stays hidden from visitors who aren’t signed in — so it’s out of the way for the public, but always there for your team and anyone who’s signed in. A first-time visitor won’t see it at all until they reveal it. (You can flip this to show for everyone — see the tip below.)

To summon a hidden button

Press and hold these two keys, then tap the up arrow three times:

Ctrl+Shift+↑↑↑it sprouts into view

Once revealed, it stays visible on that device — the visitor won’t need the shortcut again. Tip: tell your testers and clients this combo, or switch Visibility to “always visible” in Widget settings so the button shows for everyone, no shortcut needed.

Moving the button

If the button covers something, just drag it anywhere on screen — its position is remembered on that device. Double-click it to snap it back to its default corner. A single click still opens the feedback panel as usual.

Widget settings

You can control the live widget from the dashboard — no need to touch the script tag again. Open a project’s Settings → Widget settings and change any of these; updates reach the widget within about a minute.

Launcher position
Which corner the button anchors to. (If a visitor has dragged it somewhere, their choice wins on their device.)
Visibility
Hidden until revealed (the default — hidden from non-signed-in visitors until they use the keyboard shortcut) or always visible.
Sign-in
Which paths to offer: guest + account (default), guest only, or account only.
Branding
Override the widget header — its title, tagline, and the prompt line. Leave blank to keep the Sprout defaults.
These settings live entirely here — the install snippet is just the project key, so there’s nothing to edit on the website when you change them. Anything left on its default uses Sprout’s built-in default (bottom-right, hidden until revealed, guest + account, Sprout branding).

Automations

Automations run an action when something happens on a project. Create them from a project’s Automations page; each rule can be turned on or off, and you can see a log of recent runs.

Triggers — when a rule fires

New feedback
A submission lands on the board.
Status changed
A card moves columns. You can filter by from/to status, or match any move.
Comment added
Someone (staff or an agent) comments on an item.
Daily recap
Once a day at an hour and timezone you choose — sends the day’s recap from the changelog the agent published.

Actions — what it does

Slack (webhook)
Post a formatted card to a Slack Incoming Webhook URL (https://hooks.slack.com/services/…).
Slack channel
Post to a channel in a connected Slack workspace — no webhook URL needed; pick the channel from a list.
Webhook
POST a JSON payload to any HTTPS URL of your own, to hook Sprout into other tools.

A rule can have several actions; they run in order, and one failing doesn’t stop the others. Automations run out-of-band, so a slow or broken action never blocks a submission or a board move.

Slack

Connect a Slack workspace once, then route projects to channels. From a project’s Settings → Slack:

  1. 1Connect to Slack and authorize the Sprout app for your workspace. You only do this once per workspace.
  2. 2Map channels to this project. A channel belongs to one project; a project can use several channels.

With a workspace connected, you can:

  • Use the Slack channel automation action to post board events into a channel.
  • @mention the Sprout bot in a mapped channel to file feedback for that channel’s project right from Slack.

Changelog

Each project’s Changelog page has two tabs — Simplified and Technical — both grouped by the day work shipped. The agent that triages your feedback writes them: when it finishes a run it publishes the day’s release, so the changelog stays in sync with what actually got resolved. There’s no “Regenerate” button — it’s all agent-written.

Simplified tab

  • Plain-language notes for end users — no internal IDs, URLs, or submitter names. Each change is flagged a feature, improvement, or fix; features lead, and smaller improvements and fixes collapse beneath them.
  • Live in the public changelog API the moment it’s published (see the JSON endpoint on a project’s Settings page).

Technical tab

  • The technical counterpart — what changed, file names, and scope, written by the agent for your team. Team-only; never part of the public API.
  • Sprout never reads your source or makes commits — it lines the entry up with your git history by date.

Re-running the agent on the same day replaces that day’s entries (no duplicates). You can delete any entry on either tab as a cleanup escape hatch.

Agents & MCP

Two ways to let an AI coding agent work your board — both read items, comment, and change status, attributed to the agent.

The work-on-feedback skill

A Claude skill that triages and fixes items from inside your repo over plain HTTP. From a project’s Settings → Agent skill:

  1. 1Generate the agent key (a secret, separate from the project key — keep it out of public repos).
  2. 2Copy the generated SKILL.md into .claude/skills/… in your repo.
  3. 3Ask Claude to “work on [project] items” — it pulls the queue, fixes things in your code, comments, and moves cards to resolved.
  4. 4At the end of the run it publishes the day’s release — the simplified changelog and the technical log together (see Changelog above), so both stay in sync with what it just shipped.

MCP

Sprout is also a remote MCP server, so MCP-capable clients (Claude Code, Cursor, and others) can act on your boards after signing in. Find the connection commands on the global Settings page. Over MCP an agent can list projects and feedback, read an item, set its status, add comments, and publish the day’s release (simplified changelog + technical log) — across every project you can access.

Keys & settings

Sprout uses a few different keys — they’re not interchangeable:

Project key (apiKey)
Public. Goes in the widget snippet; grants only feedback ingest. Safe to ship in your site.
Agent key
Secret. Lets the work-on-feedback skill read and triage the board over HTTP. Keep it out of public repos.

From a project’s Settings page you can also:

  • Rename the project or upload a custom icon.
  • Edit allowed origins.
  • Rotate either key (the old one stops working immediately — re-copy the snippet or SKILL.md afterward).
  • Archive the project.

The global Settings page lists archived projects (to restore them) and the MCP connection commands. Everyone signs in to the dashboard with their MoJo (Microsoft) account.