Answer in brief
A client is better served by one named specialist who has the authority to decide on priorities, scope and acceptance, and who answers for the result. Public standards for digital work, from the U.S. Digital Services Playbook to the Scrum Guide, make the same point: one person, not a committee. Before signing, ask who that person is, what they can decide without permission, who covers for them, and how fast a decision, not just a reply, will arrive.
A shared inbox can answer you; it cannot decide
Many service businesses give clients an address that belongs to nobody in particular: a projects mailbox, a support form, a ticket queue. It has real virtues. Messages are not lost when someone is on holiday, several people can see the history, and the client always has somewhere to write. For routine requests that is exactly what is needed.
The weakness appears with the first question that calls for judgement. Can the launch move by a week? Is this change inside the price? Which of these two options would you choose? An inbox can acknowledge such a message within minutes. It cannot answer it, because an answer is a decision, and a decision needs someone entitled to make it and prepared to stand behind it.
So the useful distinction is not between a person and a mailbox. It is between a channel, which carries messages, and an owner, who settles them. A project can have both, and often should. What it cannot do without is the second: one named specialist who is accountable for the result and holds the authority that goes with it.
Three public standards reach the same rule: one person
The U.S. government’s Digital Services Playbook makes the rule the title of its sixth play: assign one leader and hold that person accountable. The text asks for a single product owner with the authority and responsibility to assign tasks, to make business, product and technical decisions, and to be accountable for the success or failure of the overall service.
The Scrum Guide, in which Ken Schwaber and Jeff Sutherland define the Scrum framework, is shorter still: the Product Owner is one person, not a committee. It adds a condition that is easy to overlook. For that person to succeed, the entire organisation must respect their decisions, and those who want to change the order of work can do so by trying to convince the Product Owner.
The GOV.UK Service Manual says of the service owner that they must have the decision-making authority to deliver on all aspects of a project. All three documents were written for teams building software and public services, not for a studio designing a brand or an agency running a campaign. The reasoning carries over unchanged, because it concerns how decisions get made, not what is being built.
Accountable does not mean doing all the work alone
The usual objection to a single name is that no one person can know everything. That is true and beside the point. The Scrum Guide separates the two ideas precisely: the Product Owner may do the work or delegate the responsibility to others, and regardless remains accountable. Designers design, developers build, analysts measure. One person answers for whether the whole adds up to what was promised.
The Service Manual draws the same line for quality. It calls the quality of a digital service the responsibility of the entire team and places the final responsibility with the service owner. For a client this is the practical meaning of accountability: there is one person who cannot reply that it was another department’s job when something falls between two specialists.
It also explains why the named person should be a specialist and not a message relay. The Playbook’s checklist expects the product owner to have a product management background, with the technical experience to assess alternatives and weigh trade-offs. Someone who only forwards questions to the people who understand them adds a step to every answer and takes nothing off the client’s risk.
Decisions the named person must be able to take without asking
A name on a contract is worth as much as the authority behind it. The Playbook supplies the test in the form of a key question: what does it take for the product owner to add or remove a feature from the service? If the honest answer is a meeting of five people and an email to a director, the project has a spokesperson, not an owner.
For a commercial project four kinds of decision matter. Priorities: what is done first when time is short. Scope: whether a request is inside the agreement, and what is dropped if something is added. Acceptance: whether a piece of work is finished, a duty the Service Manual gives the product manager in the form of accepting user stories when complete. And trade-offs between date, cost and quality when all three cannot be kept.
No sensible supplier gives one employee unlimited power, and a client should not expect it. What matters is that the limits are stated. In a workable arrangement the accountable project lead decides anything within the agreed budget and deadline, and the person who signs off beyond them is named. A boundary that is written down is a strength. A boundary discovered in the third week is the anonymous inbox under another name.
Continuity when the named person is ill, on leave or gone
The serious argument for the shared inbox is continuity. People fall ill, take holidays and change jobs, and a project that lives in one head stops when that head is absent. The fear is justified. The remedy is not to make everyone equally responsible, which in practice means that nobody is, but to plan for the absence in advance.
Three things make a named lead replaceable without making the role anonymous. A deputy, also named, who follows enough of the work to step in. A written record of decisions, kept where the client can read it, so that a successor inherits reasons and not only files. And accounts, files and access that belong to the company or to the client, never to one individual’s personal login.
Here the shared inbox earns its place. Used as a copy line it gives the deputy the history and the client a fallback address, while the question of who decides stays settled. Ask to have any change of lead announced in writing, with a handover period where possible. A supplier who has thought about this answers at once, because the arrangement already exists.
Two clocks: time to a reply and time to a decision
Service promises often describe the first clock: how soon a message is acknowledged. An inbox with several readers does well on that measure. The client’s schedule depends on the second clock: how long it takes until the question is actually settled. A project can collect prompt, polite replies for a fortnight and stand still.
The GOV.UK Service Standard gives the reason in its point on multidisciplinary teams: it is important that the people involved in decision making are part of the team, so that they are accountable to it and the team as a whole can respond quickly to what it learns. When the decider sits outside the conversation, every answer makes a round trip. When the decider is the person you are writing to, it does not.
Agree both clocks in writing. As an illustration only: one working day to acknowledge a message, three to decide a question that needs input from others, and a telephone number for anything that blocks a launch. Your numbers will differ. What should not differ is that working hours, time zone, the urgent channel and the route for escalation are known before the first deadline, not during it.
Questions that reveal the arrangement before you sign
Start with the Playbook’s first key question, in your own words: who is the product owner on our project? You are looking for a name and a role, not “the team”. Then ask to speak to that person before the contract is signed. If the lead appears only after the sale, you have met the sales process and not the project.
Follow with four more. What can this person decide without asking anyone? Who covers when they are away, and can I meet them? How quickly should I expect a decision, as distinct from a reply? What happens if the lead leaves the company during the project? Clear answers take a few minutes. Vague ones are information too.
Watch how the candidate behaves in that conversation. A genuinely accountable project lead asks about your goals before describing a process, declines or postpones at least one request with a reason, and is specific about what lies outside their control. Then look for the same facts on paper: the lead and the deputy named in the agreement or the kick-off note, and a line on how a change of lead is handled.
The client needs one name too, and the inbox keeps its job
The rule cuts both ways. A supplier with a single accountable lead still stalls if the client answers through a committee, with three colleagues sending conflicting comments. The Scrum Guide’s sentence applies in mirror image: the Product Owner may represent the needs of many stakeholders, and remains one person. Name your own decision-maker and tell the supplier who it is.
Nor does any of this retire the shared address. Invoices, access requests, routine content updates and out-of-hours faults are better handled by a queue that several people watch, because speed and coverage matter more there than judgement. The mistake is to route decisions through the queue, or to treat the named lead as a help desk.
A sound arrangement therefore has two parts, and a client can ask for both: a channel that never drops a message, and a person who cannot say the decision was not theirs. If an offer gives you only the first, you are buying replies. If it gives you both, with the limits of authority written down, you know who will answer for the result on the day something goes wrong.
Practical checklist
- Ask for the name and role of the person accountable for your project, and speak to them before you sign.
- Have the supplier write down what that person may decide alone on priorities, scope and acceptance, and who decides beyond those limits.
- Get the name of a deputy and confirm where decisions and access are recorded, so that an absence does not stop the work.
- Agree two response times in writing, one for acknowledging a message and one for reaching a decision, plus an urgent channel.
- Appoint one decision-maker on your own side and send consolidated feedback through that person only.
Questions and answers
Is a single point of contact the same as an accountable project lead?
Not necessarily. A point of contact receives and passes on messages; an accountable lead has the authority to decide and answers for the outcome. The difference shows in the first difficult question. If your contact has to take every request about priorities, scope or acceptance to someone else, you have a relay, and the real decision-maker is a person you have not met.
What should a project lead be able to decide without approval?
At a minimum, the order of work, whether a request falls inside the agreed scope, whether a deliverable is accepted, and how to balance date, cost and quality within the agreed budget and deadline. Decisions beyond those limits can sit with a named senior person. What matters is that both the limits and that second name are written down before work starts.
What happens to my project if the named specialist leaves?
With preparation, very little. Ask in advance for a named deputy who follows the work, a record of decisions that you can read, and accounts and files held by the company or by you instead of an individual. Ask also for written notice of any change of lead and, where possible, a handover period during which both people are available.
Is a shared project inbox always a bad sign?
No. A shared address is the right tool for invoices, access requests, routine updates and urgent faults outside working hours, where coverage matters more than judgement. It becomes a warning sign only when it is the sole route for questions that require a decision, and nobody can tell you which person will make it.
How can I check accountability before signing a contract?
Ask who will be accountable for the result and insist on a conversation with that person, not only with sales. Put the question the U.S. Digital Services Playbook suggests: what would it take for this person to add or remove a feature? Then check that the agreement or the kick-off note names the lead, the deputy and the procedure for replacing either of them.