Core concepts — workspaces, users, and seats

Almost every question that starts “why can’t I…” in ScatterSpoke resolves to one of four ideas. They’re worth ten minutes now.

The Workspace is the unit of everything

A Workspace is where people collaborate, surveys live, Ask runs, and settings apply. Billing attaches to it. Entitlements are evaluated for it. When you sign up, you create one; if you were invited, you joined someone else’s.

You can belong to more than one, and the switcher above the sidebar moves between them. Nothing crosses that boundary — surveys, responses, templates, and seats all belong to exactly one Workspace.

A User is a person; the relationship is what matters

A User is a human with an identity in ScatterSpoke. What that user can do is not a property of the user — it’s a property of their Workspace Relationship, the link between that user and one particular workspace.

That relationship decides whether they are a Seat Holder, a Participant, or both.

Both is a real and common state. Someone who answers your engineering survey this month and gets workspace access next month is one User with one relationship that changed, not two records.

Seat Holder vs Participant

	Seat Holder	Participant
Can enter the workspace	Yes	No
Builds surveys, reads results, uses Ask	Yes	No
Answers surveys	Yes, if asked	Yes — this is the whole role
Needs an account to take part	Yes	No
Counts against paid seats	Yes	No

The load-bearing row is the last one. Participants do not consume seats. They exist as records so responses can be tracked, resumed, and deduplicated — not so they can be billed.

This is why survey audience size and plan size are unrelated numbers. A one-seat Free workspace can send a Static Survey to an entire department.

The reverse is also true and catches people out: authenticating is not the same as having workspace access. A Participant who verified their email address has proven who they are for the purposes of one survey. They still cannot enter the workspace. Workspace access requires being a Seat Holder.

Seat Capacity and Seat Conversion

Seat Capacity is how many Seat Holders the workspace is currently entitled to have. Free workspaces have one. Paid workspaces have whatever their billing says.

Turning a Participant into a Seat Holder is a Seat Conversion, and it is always explicit — nobody is promoted by accident. A Seat Conversion needs spare Seat Capacity, or a billing change that creates some.

If a workspace ends up with more Seat Holders than Seat Capacity — after a downgrade, say — it is Over Seat Capacity. Existing Seat Holders keep their access and keep working; what stops is adding or converting anyone new until the numbers line up again. See seats and capacity for the mechanics.

Billing Entitlement, and why the plan you bought isn’t the answer

There are two different questions here, and conflating them is the classic bug.

Plan Tier is what the workspace purchased: Free, Pro, Business, or Enterprise.

Effective Tier is what the workspace can actually use right now.

They’re usually identical. They come apart when billing stops being in good standing — an unpaid, incomplete, or canceled subscription makes paid capabilities ineffective, so a workspace whose Plan Tier still reads Pro can have an Effective Tier of Free.

Every feature gate in the product checks Effective Tier, never the purchased tier. So if a paid feature has stopped working, the useful question is not “what plan are we on” but “what is our billing state” — the two answers can legitimately differ.

The combination of the purchased plan and that billing state is the Billing Entitlement: the workspace-level answer to what is enabled here, right now.

Where to go next

Plans at a glance — which tier gates what
Invite users and seats — Seat Conversion in practice
Managing billing — plan changes, seat changes, and invoices
Glossary — the full set of product terms