What teem is, and how the pieces fit together
Support, feature requests and a changelog in one widget and one inbox, with the loop closed at the end.
teem gives your product three things that usually come from three different tools, and connects them.
Conversations. People open the widget in your app and ask you something. Everything they send lands in one inbox, and you answer from the inbox, from Slack, or by replying to the email teem sends you.
Feedback. People ask for things, vote on what others have asked for, and watch each request move from open to shipped. The board is public, so it also answers "are you working on this?" without anyone having to ask.
A changelog. You write what shipped. It appears on your public page, in the widget, and — this is the part that is usually missing — in an email to the people who voted for the request you just shipped.
The loop
That last connection is the reason the three live together. Someone asks for a feature. Other people vote for it. You build it, publish a changelog entry, link the request to it, and teem emails everybody who voted to say it is live. Nobody has to remember to go back and tell them.
Two kinds of reader
Most of teem is for whoever answers the messages and decides what gets built. One part is for an engineer: the install, which is a script tag and one function call. It takes a few minutes and then nobody has to think about it again.
Anything the dashboard can do, an API token or an MCP tool can do too. If you would rather run your inbox from an agent than from a browser, that is a supported way to use teem, not a workaround.
Where to go next
- Install teem in your app — a script tag and one call, and the widget is live.
- Invite your team — the people who will be answering.
- How people reach you — what your users see once it is in.
- Before you go live: a checklist — everything to check before you tell your users.