In a three-person team everyone sees every customer and that is fine. At fifteen people the same setup turns into three separate problems: reps call each other's customers, the risk of data leaving increases, and nobody knows who owns what.
Two different things: visibility and ownership
They get conflated, but they are not the same.
- Ownership is who is responsible for a customer. Tasks land with them; they answer for the outcome.
- Visibility is who can see which record.
A rep who does not own a contact may see the record without working on it. In most teams that is the right design: broad visibility, clear ownership.
When visibility must be narrowed
In some businesses visibility genuinely has to be restricted: branches should not see each other's customers, a contractor team should see only its own work, an intern should not be able to download the entire customer list.
The critical distinction here: hiding a menu is not a security control. Removing a screen from the menu does not prevent access to that data; it only tidies the interface. Real protection happens at the data layer — which user can read which rows must be defined in the database itself.
Setups that conflate these two layers discover late that a module they believed "closed" was in fact readable.
Assignment rules
In teams where assignment is manual, a share of records always stays ownerless. Three automatic rules largely solve it:
- By source. Web form leads to sales, support requests to support.
- Round robin. Records of the same type are distributed in turn.
- First contact. Whoever speaks to the customer first becomes the owner.
Whichever you choose, ownerless records need a default owner. Otherwise they appear on nobody's list.
When ownership changes
Two things are needed when the owner changes: a record of the change and notice to the customer. The record answers "who was handling this customer?" later. Notifying the customer protects the relationship — when a new rep calls without introducing themselves, the customer has to start over.
Export and bulk action permissions
Two permissions deserve separate thought from visibility:
- Export. Not everyone who can see a list needs to be able to download it.
- Bulk actions. Bulk delete, bulk tagging and bulk messaging produce hard-to-reverse outcomes when misused.
Keeping these two narrow reduces risk markedly without making daily work harder.
When creating a new user
When adding a team member, the default permission set should be predefined. Accounts opened with broad access "to be trimmed later" never get trimmed. The correct order is the reverse: start narrow, open up as needs arise.
Tomorrow we look at the first task of the morning: summarising what piled up overnight.