Summary

  • Single-Channel Guests are free on paid workspaces, with up to five for each paid active member; Multi-Channel Guests are billed as regular members.
  • An additional-channel request, an approved role change, billing activity and a completed handover are different events. None alone establishes the others.
  • Changes in the paid active-member base warrant a capacity review, not an unsupported prediction that existing guests will be automatically removed.

The second room is a purchasing decision

An external specialist joins a project channel, does the work and later needs access to the team coordinating the release. There need not be another person or a longer contract. The requirement has changed from one room to two. In Slack, that modest change can cross the line between two account roles with different billing treatment.

Slack’s guest documentation says Single-Channel Guests can access only one channel and are free on paid plans. Multi-Channel Guests can access the channels specified for them and are billed as regular members. A short list of permitted channels is therefore not the same thing as a free account. The paid role can remain tightly restricted.

That distinction matters to buyers of collaboration software. Headcount is a poor description of the purchase when the commercial boundary is permission breadth. A budget that records one contractor but not the role needed for that contractor misses an input to expected charges. Conversely, paying for a multi-channel role is not necessarily evidence of waste. It can be the appropriate price of a real, approved requirement.

The useful question is not how to keep every outsider free. It is whether the person needs a single, coherent working space or several areas whose information should remain separate. That is a judgment about the work and its boundaries before it becomes a judgment about the subscription.

Free access has a paid denominator

There is another condition behind the attractive free role. Slack allows up to five Single-Channel Guests for each paid active member in a workspace. Its documentation illustrates the rule with ten members and fifty single-channel guests. This is not an independently purchasable free guest plan. Guest accounts are available on paid plans, and paid plans apply at workspace level, not to one isolated account.

The denominator is consequential. A supplier-collaboration plan based on a historical staff directory may not describe the paid active-member base on which the invitation allowance is stated. The people running an external project and those reviewing paid-member activity therefore have related planning questions, even if they belong to different budget owners.

The rule supports a bounded inference: when that base changes, the assumptions behind a proposed guest invitation programme should be revisited. It does not establish when Slack recalculates available invitations, how an over-quota workspace would be handled, whether a grace period exists, or whether existing guests would lose access. None of those implementation claims follows just from multiplying a member count by five.

A responsible review consequently distinguishes a documented allowance from observed account state. It records the applicable rule, the current information available to the administrator and any unresolved entitlement question. It does not announce an impending eviction merely because a spreadsheet’s denominator has fallen.

Activity is not authorization

Slack’s Fair Billing Policy provides a separate account of paid activity. The policy is expressly scoped to plans and add-ons purchased through Slack’s website and paid for by credit card or self-serve invoicing. It should not be silently extended to every negotiated agreement.

Within that scope, paid roles include owners, administrators, full members and Multi-Channel Guests. Single-Channel Guests and bots are free. A member who has not used Slack in more than 28 days becomes inactive for billing. If that person starts using Slack again, the change is detected and prorated charges resume.

This is a billing classification, not a substitute for access review. An inactive account is not necessarily a deactivated account. A contractor’s absence from Slack does not demonstrate that the project has ended, that another person has accepted responsibility, or that the account’s existing permissions remain appropriate. Equally, legitimate renewed use can be the necessary completion of a task rather than suspicious activity.

The distinction prevents a common conceptual shortcut: treating a smaller bill as proof of a smaller authorization surface. The two can move together, but the billing policy alone does not prove that they have. Permission scope must be checked as permission scope.

The policy also describes prorated credits for unused time, applied to future payments. These credits are non-transferable and non-refundable and expire when the paid plan terminates. They are not cash recovered from a former member. Expected credits can be useful to the buyer, but they should not be presented as an immediate refund available to finance another service.

An approval has to become a verified change

Slack allows members to request additional channels for Single-Channel Guests. Workspace Owners and Admins receive the upgrade requests and may approve or deny them. Guest role management belongs to administrative roles; a project participant’s request is not its own authorization.

The commercial significance lies in the handoff between the person expressing a need and the person accepting its consequences. A request may explain the required second channel. Approval may establish that the organization accepts broader access. The resulting account role and completed channel access still need to be verified. An approval message alone is not evidence that both the permissions and the expected billing treatment have changed correctly.

This does not require an elaborate new purchasing bureaucracy. A compact decision record can identify the required channel scope, the responsible approver, the intended account role and the relevant plan or contract basis. Once the approved change is complete, the record can capture its verified state. Where the administrator cannot establish the current allowance or contract treatment, the uncertainty should remain visible.

This record is an editorial recommendation, not a feature that Slack requires or a finding that a particular customer lacks controls. Its value is simply that project urgency and subscription consequences become part of the same decision rather than passing unnoticed between teams.

Expiry is a date, not a handover

Guest administrators can choose automatic deactivation after an interval, a custom date or indefinite access. Slack says that the guest and the owner or administrator who set the date receive a reminder five days before deactivation.

An expiry date can therefore be a useful project boundary. It does not establish that the deliverable was accepted, an unresolved issue was assigned to someone else, or the guest received everything needed to leave the work in a usable state. The reminder signals an approaching access change; it cannot attest to completion.

Nor does a time limit make a Multi-Channel Guest free. Slack explicitly says those accounts are still billed like regular members, with prorated credits where they are active for only part of the billing cycle. Access duration and account role are separate commercial inputs.

The buyer should avoid another inversion: keeping access open indefinitely because a handover is difficult, then calling the absence of an expiry a continuity plan. Continued access may sometimes be justified, but the reason and accountable owner should be explicit. Continuity of the work is not demonstrated merely by the survival of a login.

A cheaper shape can be the wrong shape

A single-channel arrangement can be genuinely efficient for a bounded external task. But collapsing several workstreams into one channel solely to preserve a free role can widen the information made available to every participant in that channel. This is a hypothetical organizational risk, not evidence of a Slack incident or a limitation on every customer’s design.

The alternative is not automatically to buy broader access. Slack’s comparison of guest accounts and Slack Connect describes different collaboration arrangements: a guest enters the host workspace, while participants in Slack Connect use their own workspace. The guide also distinguishes access to communications and files after guest expiry from each company’s ability to retain a record after a connected channel is disconnected.

Those are architecture and custody distinctions, not an unconditional promise about preservation or deletion. They also do not establish that every Slack Connect use case is free or permitted under every plan. A different arrangement requires its own entitlement and information-handling assessment.

The commercial conclusion is modest but useful. Buy the collaboration boundary that fits the work, then understand its role, activity and duration consequences. Free access is a benefit within that boundary—not a reason to make the boundary less truthful.

Sources