For the complete documentation index, see llms.txt. This page is also available as Markdown.

Support & Feedback

Support & Feedback is how you report bugs, request features, and get hands-on help from the team without leaving TheContentForge. Everything happens inside your workspace; reporting is only available to signed-in active users.

Where it lives

Three entry points:

  • Sidebar menu - Report Issue (bug) and Request Feature (feature) buttons near the help links

  • Support Inbox - /support shows every ticket you've opened, with status badges. Investor Intel workspaces use /intel/support.

  • Inline error states - failed AI jobs in the generation queue show a Report button that pre-fills a bug with the failing job id, status, and visible error

Reporting is not available from the public landing, pricing, or FAQ pages - you need to be signed in.

Bug reports vs feature requests

  • Bug report - Something is broken or behaving unexpectedly. Captures a title, description, severity (low / medium / high / critical), affected section of the app, impact scope (just you, one workspace, multiple users, or everyone), whether it's blocking your work, whether you have a workaround, and manual attachments. Uploads are limited to 10 files per submit or reply, 30 files per ticket, and 25 MB per file. The app automatically attaches diagnostics: browser, viewport, app version, current URL without query strings, and a short trail of recent activity events.

  • Feature request - Something you want that doesn't exist yet. Captures a title, description, category, impact scope, and attachments. Severity doesn't apply.

The submission form keeps required fields short. A 3-character title and 10-character description are the minimums, but more context shortens triage time. The form also has a Copy debug context button that copies the technical diagnostics - and, for bugs, your recent activity trail - to your clipboard as JSON, handy when the support team or a teammate asks for it directly.

Your Support Inbox

/support is your personal inbox. Each ticket shows:

  • Reference code (e.g. BUG-0042 or FEAT-0017)

  • Title and a snippet of the description

  • Current status badge

  • Last activity time

Click a ticket to open /support/:refCode and see the full thread.

Ticket detail and thread

The ticket page shows the full submission, every comment, every attachment, and any system events (status changes, assignments, info requests).

You can reply at any time:

  • Composer - Type a follow-up comment with up to 10 attachments per reply. Replies are scoped to your ticket and visible to you and the team handling it.

  • Resolution banner - If the ticket has been resolved, marked shipped, declined, or any other terminal status, the resolution note shows at the top.

  • Needs info banner - If support has asked a specific question, the question shows in a banner so it's obvious what to answer.

Status meanings

Status
What it means

Open

Submitted but not yet picked up

Triaged

The team has reviewed and categorised it

In progress

Someone is actively working on it

Needs info

Waiting on a clarifying answer from you

Planned

Feature request scheduled for future work

Shipped

Feature request delivered

Resolved

Bug fixed

Won't fix

Bug acknowledged but won't be addressed (with reason)

Declined

Feature request declined (with reason)

Duplicate

Linked to another ticket already being tracked

Grant support access

On an open ticket you'll see a Grant support access button. Clicking it lets the support engineer working on your ticket see your workspace so they can investigate hands-on - useful when a bug is hard to reproduce or you'd rather have someone look directly than walk you through it.

You stay in control:

  • You grant access manually - it's not on by default

  • You can Revoke at any time from the same ticket card

  • It ends automatically when the ticket closes

  • It doesn't use one of your workspace's paid user seats

  • It is scoped to that one ticket - closing it doesn't open a back door for future work

If you'd rather not grant access, you don't have to. Comments and attachments are usually enough.

Notifications

The support team receives a notification when you open a ticket, when you add a comment, and when you grant or revoke support access. Replies on your tickets surface in your Support Inbox.

Workflow

  1. Hit Report Issue or Request Feature from the sidebar menu, or click a Report button from a failed generation job

  2. Fill in title and description; add severity, impact, and optional screenshots or logs as attachments

  3. Submit - you'll be taken to the new ticket at /support/:refCode or /intel/support/:refCode

  4. Reply to follow-ups, grant support access if asked, and watch for status changes

  5. The ticket moves to a terminal status (Resolved, Shipped, Won't fix, Declined, or Duplicate) when it's done

Tips

  • For bugs, attach a screenshot or screen recording - it usually shortens triage by a lot

  • Severity matters: reserve critical for "publishing is broken" or "data is at risk." Don't inflate severity to skip the queue; it goes against the way the team prioritises

  • If a bug isn't reproducible from your description, support may ask to use Grant support access - granting it is faster than a back-and-forth

  • Feature requests live longer than bugs. They flow through Planned → Shipped as roadmap allows; keep them focused on the problem you're trying to solve, not a specific implementation

Who can use it

Support is available to all signed-in active users in active workspaces. If your workspace is past its grace period or soft-deleted, support reporting is disabled until the workspace is restored.

  • User Roles - every role can submit tickets; visibility on each ticket is scoped to the reporter and the support team

  • Account - for billing or workspace settings issues, check the Account page first

Last updated

Was this helpful?