Several writers on one account: team, roles and access
A newsroom is not one person. Who can generate audio, who approves, who touches billing: WeDispatch's roles, what each one opens and closes, and why sharing an account is not sharing a password.
In a newsroom, nobody does everything. A reporter writes and wants to hear the piece before it goes out. A sub-editor proofreads and approves. Someone, usually one person, keeps the billing and the technical settings. A tool that knows only a single login then forces a bad habit: passing the same credentials from hand to hand. It is convenient for a month, and it becomes a problem the moment someone leaves, a technical key is created by mistake, or you need to know who changed a setting.
WeDispatch organises this work by roles. The idea fits in one sentence: several people work on the same workspace, each with their own identity and a scope that matches what they do. Here is what each role opens, and above all what it closes, because that is where a team's peace of mind is won.
Three levels, described by what they can do
At the top, the account owner. This is the person who opened it, and it is their card that pays. They alone manage the subscription: subscribing, changing the monthly volume, opening the payment portal. This is not arbitrary; they are the one the financial commitment concerns, and no one else should be able to change it.
Below that, you assign two roles to the people you invite. The administrator runs the account: they manage the team (invite, remove, change a role), the technical access keys, the connected sites, the voices and the profile settings. They do everything the owner does, except touch the subscription. The member produces day to day: they generate audio, correct it, approve it and read the listening statistics. They manage neither the team, nor the sensitive settings, nor the billing.
This split has a history we would rather tell than hide. For a while, a member's role was checked in only one place in the code. A plain member could, in practice, create or revoke access keys, open the billing portal, edit sites or replay every account setting, while their own screen promised the opposite. An internal audit caught it, and the rule is now enforced everywhere, on both sides: changing an account setting requires owner or administrator, managing the subscription requires owner, and any missing, null or unknown role is refused by default. Access closed by default beats access left open by oversight.
Why a shared login is not a role
The difference is concrete. When someone leaves the newsroom, you remove their access without changing anything for the others: no new password to circulate. When a technical key is created, it carries the name of whoever created it. When audio is approved, the approval is timestamped and attributed to its author. None of that exists when six people log in with the same credentials. Sharing a password also means sharing responsibility until it belongs to no one. It is the same reasoning we apply to where your text travels, set out in where your text goes: what is traced and attributed is what stays under control.
Roles also serve a newsroom's workflow. A member generates and corrects; a review can be required before publication, and approval falls to whoever you entrusted it to. We described that handover in reviewing audio before publishing. Roles are not a security layer bolted on top: they follow the way a team already divides the work.
Joining a team, without a nasty surprise
An invitation goes out by email. The invited person signs in and joins the workspace that invited them. One point is worth stating, because it was fixed after the fact: someone who already owns an active WeDispatch account, with their own articles or settings, is never silently folded into the inviting team. Their data would become unreachable without their having chosen it, so the invitation is refused on screen, with its reason. Only a person whose account is entirely empty joins the team. The rule is explicit rather than guessed, and that is what stops someone from waking up one morning inside a workspace that is not theirs.
The same machinery holds when you run several sites. One team, several connected sites, a single subscription: we take that up from the organisational angle in managing several sites on one account. Roles and multi-site answer the same question, that of a structure that is not a lone individual.
What to look at before you commit
If you are evaluating an audio tool for a newsroom, ask three simple questions. Can I invite my colleagues without handing out my password? Can I decide who approves and who only produces? Who, exactly, can touch billing and the technical settings? The answer says more about a product's maturity than any feature list. With us, those answers are legible on the French text-to-speech page and in the detail of the team and roles feature: an owner who keeps a hand on the money, administrators who run the account, members who produce, and access closed by default for everything else. A team shares the work; it should never have to share a key.
Give your articles a voice with WeDispatch
This blog is itself voiced by WeDispatch. Curious how it sounds on your content?
Book a demo