ZopDay Developer Seats: Assign Now, Reduce at Renewal
A growing team adds members faster than it buys seats. When the invite lands before the purchase, the new member sees a dashboard they cannot use. Nobody told them they are waiting, and nobody told the admin that a seat is missing.
ZopDay makes the gap visible. Admins assign and unassign developer seats in Settings. Members who exceed the purchased seat count show a Waiting status instead of silently failing. A seat queue is the ordered list of members who have access and members who are waiting, so the admin sees exactly who is active and who is blocked.
Admins Control Every Assignment
Only admins assign and unassign seats. A member cannot claim a seat on their own. The assignment list shows every member with their current status.
| Status | What it means |
|---|---|
| Assigned | The member has an active seat and full access |
| Waiting | The member is beyond the purchased seat count |
Unassigning a member frees their seat immediately. The admin can then assign that seat to a different member. The role-based access model ensures that only admins see the seat management controls. Viewers see their own status but cannot change assignments.
Admins control every assignment directly. The seat list shows who is assigned and who is waiting, so the team always knows the current allocation.
Adding Seats Works Anytime but Reducing Waits for Renewal
Seats can be added at any time through a new purchase. The new seats stack on top of the existing count. If a team bought 5 seats last month and buys 3 more today, the total becomes 8. Each purchase is tracked separately, and the seat count adds up across every transaction.
Reducing seats works differently. A team cannot drop its seat count mid-cycle. The reduction takes effect at the next renewal date. This prevents a team from paying for 10 seats, using them for 29 days, and then dropping to 5 on the last day of the billing period.
Teams deploying VM services under a plan with a service limit should check whether the seat count and the service limit align. A Pro plan with 20 seats but a lower service cap means some developers have seats but no deployable service slots.
The Queue Stops Helping When Everyone Is Waiting
The Waiting status appears when members exceed the purchased seat count. On paid plans with a fixed number of seats, this makes the gap between the team size and the seat budget visible.
If 8 members exist and only 5 seats are purchased, the remaining 3 show as Waiting. Admins assign and unassign seats directly, so the team always knows who has access and who is blocked.
Teams using tag-based cost reports to track spending by team can track seat purchases alongside other costs. The seat count adds up across every purchase, so the total always reflects the cumulative spend.
