How to run department approvals on a store launch without email chains
Legal, Accounts, and Operations all need to sign off during a launch. Here is how to structure those approvals so they are fast, enforceable, and auditable.
Every store launch has a handful of moments where someone outside the launch team has to say yes. Legal on the landlord agreement. Accounts on the deposit release. Operations on the layout. Legal again on the licences. Accounts again on the opening order.
These are a small fraction of the tasks and a large fraction of the delay, for a reason that is worth stating plainly: an approval is the only kind of task where the person who needs it cannot do it themselves.
Why email and chat fail at this specifically
An approval request in email or WhatsApp has no state. It is a message. It has been sent, and that is all the system knows.
That produces three recurring problems. Nobody can see the queue, so a reviewer with eleven pending approvals across six stores has no list — only an inbox where approval requests compete with everything else. There is no aging, so a request sitting for nine days looks identical to one sent this morning. And there is no record: "Legal approved this" ends up being a claim by the launch coordinator rather than an action by Legal.
Structure approvals around four properties
An approval that works has four properties, and they are all structural — none of them can be achieved by asking people to be more diligent.
1. It blocks
The task cannot move to done until the approval is granted. If the approval is advisory, it is not an approval, and it will be skipped under deadline pressure by someone acting in good faith.
2. It is addressed to a department, not a person
Route to Legal, not to a named lawyer. People take leave, change roles, and leave companies mid-launch. An approval addressed to an individual becomes permanently stuck the week they go on holiday; one addressed to a department is picked up by whoever is covering.
3. It carries its evidence
The reviewer should not have to ask for the document. The signed agreement, the photograph, the invoice — attached to the task itself. Most approval delay is not deliberation; it is the round trip of asking for what should have been attached.
4. It leaves a record
Who approved, what they approved, when. Timestamped and immutable. This is what makes a postmortem a lookup instead of an argument, and it is what protects the approver as much as the requester.
Partial approvals are not a failure mode
Real reviews are frequently conditional. Legal approves the agreement subject to one clause being amended. Operations approves the layout except the back-of-house door swing.
Systems that only model approve-or-reject push this reality into a comment thread, where the condition is recorded as prose that nobody enforces. Then the task closes and the condition evaporates. Model the partial approval explicitly: approved, with a recorded condition that itself has to be closed out.
The queue matters more than the request
The most under-appreciated part of this is what the reviewer sees. Legal is not working on your launch; Legal is working on eleven launches plus their actual job.
Give them one list — every approval waiting on their department, across every store, sorted by how long it has been waiting and how close the associated opening date is. That single view is usually worth more to launch velocity than any amount of chasing, because it converts an invisible obligation into a visible one.
What this looks like in practice
In FranchiseLaunch, approvals are a property of the task: you mark which department must sign off, the task cannot close until they do, the reviewer gets a department-scoped queue and a push notification, and every decision — including partial ones — is written to the activity trail with an author and a timestamp.
If you are currently doing this in a spreadsheet plus a group chat, this post covers why that combination degrades as the number of concurrent launches grows.
