TellenzeFeedback to work
A customer message, an error report or a service alert can reveal a problem. Use Signals to keep the incoming evidence, review related reports and choose the work that will help.
Signals requires Starter or above. Processing also depends on workspace setup and AI availability.
An outcome with its evidence
Start with what arrived
Open Work → Signals → Add signal. Supply the report and source, then save. Use Add evidence on an existing signal when the new report concerns the same issue.
Captured reports stay fixed as the signal changes. Keep the incoming words, relevant source link, event identity, occurrence time and supplied metadata. Append new evidence rather than rewriting the original report.
Reports are shared within the workspace. A source link retains its own access requirements. Do not put private credentials or unrelated private material into shared evidence.
Starting projects can identify up to 20 active Projects you can access. These are routing hints: they neither create work nor limit a signal to one Project.
Later, use Associated projects → Edit projects to correct its current context. Original intake Projects remain with each report in Evidence.
Submit text, links and metadata through the web, MCP, Looper or an App integration you build. Native Discord and telemetry connectors are not included.
The manual Add signal flow does not upload files. Use Forms for configurable questions and scanned file attachments through Custom Forms.
Read the Forms setupIllustrative receipt-download example
Two customer messages and an application report may describe the same problem. Keep all three reports, compare their times and sources, and review the proposed connection.
A shared symptom is a reason to investigate. It does not prove the same root cause. If the reports describe different issues, correct the grouping before choosing the work.
Report count, distinct sources and source-reported occurrence totals are different measures. Retried delivery is not a new incident, and overlapping reporting windows should not be added into an invented total.
“The receipt button did not work on my phone.”
“My order is paid, but I cannot download the receipt.”
“The receipt endpoint returned HTTP 503 during the supplied window.”
Suggested investigation
Check the supplied reports and logs. Explain the cause, affected scope and next step before claiming a fix.
A member reviews the Project, scope and acceptance criteria.This diagram illustrates a workflow. It is not a shipped incident, automatic connector or verified diagnosis.
Review the evidence before the proposal
Looper organizes changed evidence and can suggest work for eligible workspace-visible Projects. Private Projects and private assistant conversations are outside shared background analysis.
Check the original reports, source details, receipt and occurrence times, links and reporting windows. When the current evidence is understood, choose Mark evidence reviewed.
Correct a merge or split when needed. Once work is linked, grouping changes require an explicit review of the evidence and work allocation. Original report identities and accepted-work receipts remain intact.
Review the Project, optional Focus, work type, title, context, acceptance criteria and severity. Use Edit suggestion and Save suggestion to improve it before acceptance.
Choose Accept & create work, Link existing work, or Dismiss. Accept only the useful scope, and check the resulting native work. Repeating acceptance returns the existing work item.
Changes to evidence or Required Context require a fresh review. Incoming report text is evidence, not authority to change policy or permissions.
From intake to a checked outcome
The board labels and underlying states describe the same lifecycle. Processing health is separate: a provider failure neither discards evidence nor completes the work.
Received · The original reports await organization. Keep the source and what happened.
Ready · Evidence is organized, with zero or more suggestions. A group can contain just one report.
Accepted · At least one resolution item is linked. Other suggestions can still need a decision.
In review · Resolution work is complete, every suggestion has a decision and current evidence is reviewed.
Shipped · A member confirms resolution and records the outcome. The evidence remains historical.
In Linked work, Resolution links determine review readiness. Context links supply background and do not count toward completion. Archived incomplete resolution work still blocks readiness, and 100% work completion still needs the signal’s review and shipping checks.
Confirm the actual resolution
When resolution work is complete, every suggestion has a decision and current evidence is reviewed, the signal can reach In review. You need access to every resolution link before confirming it is shipped.
Choose Mark shipped, write a Resolution outcome explaining how the work addressed the evidence, then choose Confirm shipped. Completing a native task alone does not ship the signal.
New evidence during review returns the signal to Accepted, shown as In progress on the board. Review that evidence before shipping. It does not silently change an existing task’s scope.
Work at a useful pace
Manual triage and discussion remain available when Looper is unavailable. A processing interval controls when analysis may start; it does not promise when it will finish.
The default is hourly. An administrator chooses manual mode or an allowed interval in Admin → Settings → Signals. Process now, MCP and Looper share the same workspace run and plan minimum; repeated requests are combined.
Processing uses existing AI allowances. Queued or running requests keep the button unavailable. Check displayed failures or limited coverage instead of assuming analysis is complete.
In Discussion, mention a teammate or @looper to ask about the evidence or missing details. Replies stay in the shared signal conversation. Private Looper history is not copied there automatically.
Discussion does not create tasks or change workflow. Use it to decide whether a proposal is useful and feasible. If suggestions are missing, read the explanation, add evidence or choose Reconsider suggestions on an unaccepted Raw or Grouped signal.
Accepting a proposal creates or links native work. Plan its priority, ownership and capacity through the destination’s normal work process.
| Plan | Minimum interval |
|---|---|
| Starter | 30 minutes |
| Team | 15 minutes |
| Business | 5 minutes |
| Enterprise | 1 minute |
Use the right connection for the job
Connected agents can discover submit_signal, list_signals, get_signal, process_signals and manage_signal. Read current signal and proposal versions before a change. Accepting work follows the destination’s current Required Context and needs its delivered receipt where required.
Apps need explicit signals:write or signals:read grants. The App API submits and reads evidence; it cannot accept suggestions, discard signals, change workflow or request processing. Use a stable client_submission_id for retries of the same report. Changing evidence under the same identity returns a conflict.
Keep a way back
Filtered holds likely noise with an explanation. Discard signal records a member’s reason. Both preserve original evidence and can be restored.
Administrators manage Noise rules. Source keys match exactly and are case-sensitive; every report in a group must match the same enabled rule. Rules run during processing. A reason explains the rule; it is not a keyword condition.
Before restoring filtered work, change or disable the matching rule if needed, then choose Restore signal. Saving or disabling a rule does not automatically reprocess or restore earlier signals. If the rule still matches, later processing can filter the signal again.
Reports arriving after shipping create a recurrence or join an open one. Keep the shipped outcome historical, and record why you relate the new signal.
A similar symptom can suggest a recurrence or possible regression. It does not prove a confirmed regression. Accepted work and completed outcomes are never merged automatically.
The board shows completed signals from the last 30 days by default. Older signals remain in History, permanent links and related-signal history.
A few useful details
No. Reports remain evidence. Organization can produce zero or more suggestions. A member reviews scope, creates or links useful work, and dismisses suggestions that do not help.
This release accepts text, links and metadata through the web, MCP, Looper and your own App integration. Native Discord and telemetry connectors are not included. Use Forms when your intake needs configurable questions or scanned file attachments.
Yes, with explicit evidence and work-allocation review. Original reports and accepted-work receipts remain. Check how linked work follows the merge or split rather than accepting a duplicate task.
All Resolution work must be complete, every suggestion needs a decision and the current evidence needs review. Context links do not count. A member then confirms the signal’s resolution and records an outcome.
No. All processing requests share the workspace cadence and subscription minimum. Manual triage and discussion are available immediately. The interval governs when processing can start, not completion time.
The board and processing lock, while Signals data is retained and existing native work remains usable. Previously published Custom Forms can still collect raw evidence; managers read their original responses and files in Forms. Paid access restores Signals and linked-work progress.
Show what the response achieved
Keep the original report, choose a response your team can deliver and share the result with the people who need it.
Keep your next step clear
COME TAKE A LOOK
Curious? Join the waitlist and see how we welcome your team.
Tell us a little about your team. We’ll explain the next steps and invite you when we have capacity for your workspace.
Join waitlist Start with your email. No payment needed to join.