Inkpilots

Assistant and Public Chat

Workspace

Assistant and public chat turn a public workspace from a passive reading surface into an interactive one. In Inkpilots, this is a managed workspace feature with explicit enablement and monthly token controls. It should be treated as an operational feature, not just a UI enhancement.

This page explains what the current product supports, when public chat is useful, and how to manage it responsibly.

What this feature is for

Use public chat when your workspace needs to:

  • help visitors navigate a large or complex public surface,
  • answer common questions in a conversational format,
  • make the workspace feel more guided and service-oriented,
  • support exploration without forcing visitors to click through every page manually.

Public chat is most valuable when it deepens understanding and helps visitors reach a clearer next step.

What the current settings control

The current public chat settings surface lets workspace owners manage:

  • whether public chat is enabled,
  • the monthly token limit for that public chat usage,
  • the currently used tokens for the active month,
  • the current usage month.

This makes public chat a controlled public feature rather than an unbounded assistant that can consume resources indefinitely.

Access and plan considerations

In the current product, public chat is not simply available to every workspace configuration. The feature is plan-aware and owner-aware.

That matters because enabling public chat is tied to subscription level, not only to product preference. If the workspace does not meet the required conditions, the UI prompts the user toward an upgrade path instead of silently pretending the feature is fully available.

Operationally, teams should treat public chat as a premium interactive capability with real cost and governance implications.

Why token limits matter

Public chat consumes tokens. That means the quality and visibility of the public workspace directly affect resource use.

The monthly token limit exists to let the workspace decide:

  • how much public interaction it wants to allow,
  • how aggressively the workspace should expose chat to visitors,
  • how to keep the feature sustainable across a month.

Without a limit, a popular workspace could create uncontrolled usage. The current settings surface makes that tradeoff explicit.

When public chat is a good fit

Public chat is usually worth enabling when:

  • the public workspace already has enough content to support meaningful answers,
  • visitors are likely to have repeat questions,
  • the workspace is designed to guide people toward information, support, or action,
  • the team is prepared to monitor the usage budget.

It is usually a poor fit when the public workspace is still thin, the messaging is unclear, or the content base does not yet provide useful context for an assistant to draw from.

What to confirm before enabling it

Before turning public chat on, teams should verify that:

  • the public workspace is already understandable without chat,
  • the header, identity, and CTA layers are coherent,
  • published content is accurate enough to support questions,
  • the monthly token limit matches the expected level of interaction.

Public chat should strengthen the public experience. It should not be used to hide weak presentation or incomplete content.

Recommended operating practice

Start with a reasonable token cap

Begin with a limit that reflects realistic traffic, then adjust after observing real usage.

Pair chat with a strong public surface

The assistant works best when the workspace already has good structure, clear identity, and a meaningful content base.

Monitor monthly usage deliberately

Do not enable public chat and ignore it. Used tokens should be reviewed as part of ongoing workspace operations.

Treat enablement as a public-facing commitment

If visitors can chat with your workspace, they will treat that as part of your public product quality. Enable it only when that interaction is worth having.

Common mistakes to avoid

  • Enabling public chat before the workspace has enough content to support useful answers.
  • Treating chat as a substitute for good presentation and navigation.
  • Setting no meaningful token policy for public usage.
  • Forgetting that public interaction is both a user-experience decision and a quota decision.

How this page connects to the rest of the handbook

Use this page together with:

Related guides