← Back to docs

Live support and suggestions

Live support and suggestions

Tools provides live support for signed-in users and guests, plus a public suggestion board for product ideas and feedback.

Signed-in support

Open /me/support to start a conversation and follow earlier conversations. Replies appear on the page without a full reload while the page is open. A signed-in user can only read and write their own conversations.

Support staff can take over and answer the same conversation from the administrator support workspace. Administrators can also start a support conversation manually for a Tools user.

Guest support

Open /support/live if you are not signed in. Tools creates a private browser support session and uses it to keep your guest conversations separate from other visitors. The guest session is required to continue reading or replying to a conversation; knowing a conversation reference alone is not enough.

Authorized support staff can see limited session context needed to identify and troubleshoot the guest conversation, including first/last visit time, browser information, the related page and network address. Tools does not copy passwords, authentication tokens, cookies or request payloads into the support record.

Slack support reporting

Support chat activity is also copied to a dedicated private support channel in Slack so the support team can follow conversations. This includes chat text and safe conversation context. Operational Slack delivery failures do not block the conversation itself and are reported separately to Tools operations.

Public suggestion board

Open /suggestions to browse public feedback or publish a new suggestion. The form has two independent dropdowns:

  • Service - derived directly from the current /services catalogue, plus a general Tools platform choice. A service card that is added, renamed or removed from the catalogue automatically changes the suggestion choices as well.
  • Feedback type - new feature, improvement, good/works well, bad/works poorly, integration, problem/bug or other feedback.

New submissions explicitly acknowledge that the selected service, feedback type, title and description are public. A relevant URL is private by default and is published only when the submitter selects the public-URL option.

Submitter identity is separate from the public suggestion. Tools does not show the linked user account, optional guest name/email, private support replies or support audit data on public suggestion pages. Historical suggestions created before this public-board workflow remain private until an authorized support administrator explicitly publishes them.

Possible statuses are new, reviewing, planned, implemented, rejected and closed.

Administrator management

Authorized administrators can open Suggestions & feedback directly from /admin. The suggestion list supports status changes without opening each item, while the detail page still provides publication controls, private support replies and GitHub issue creation. Administrators can permanently delete unwanted or test suggestions after confirmation; private suggestion replies are removed with the suggestion, audit history is retained, and an already linked GitHub issue is left unchanged.

Copilot and GPT implementation instructions

Every public suggestion has a copyable implementation instruction generated deterministically from its public fields and the permanent ToolsAPI development rules. The instruction identifies the affected service, feedback type, requested change, testing expectations, GUI/API/access-control/audit checks, documentation requirements and the rule that first-party Tools API URLs remain unversioned.

Private contact data and private support replies are never added to the generated instruction.

GitHub development tickets

Authorized support administrators can create a GitHub issue from a reviewed public suggestion. Suggestion tickets are restricted to Tornevall/toolsApi; the administrator only configures a fine-grained GitHub token with issue-write access to that repository. The token is encrypted at rest and is never rendered back into the browser.

Issue creation is server-side and reuses an already linked issue when the action is repeated. The created issue contains the public suggestion and generated implementation instruction only. Successful and failed operations are recorded in the support audit trail, and operational failures are also sent through the normal always-on Tools diagnostics path without credentials.

Once an issue is linked, its GitHub URL is shown on the public suggestion page.