Weekly ops meeting agenda for Shopify brands

The agenda

Same day, same time, every week. Thirty minutes. Five recurring items with one named owner each, then a closing pass over the action list.

Thirty minutes is our recommendation for a lean team, not an industry standard. Longer formats exist. Lucid Meetings publishes a weekly leadership meeting built as a working meeting rather than a reporting one, and that is the part worth keeping at any length: the time goes on problems, not on everyone describing their week.

The meeting has a second job, and it is the reason to run it this way. Every recurring item on that agenda is already backed by a procedure somewhere. The weekly conversation is where you find out that procedure has stopped being true.

One number per item

Pin every item to one number, or the meeting turns into opinions.

• Fulfilment: split on-time shipping from on-time delivery. The first is whether orders left the building when promised. The second is whether the carrier arrived when the customer was told. They fail for different reasons and have different fixes.
• Support: ticket volume by tag. A spike in one tag points at a cause. A spike in total volume just points at a bad week.
• Returns: how long a return takes from arrival to refund. A return sitting on a shelf is money you owe a customer and stock you cannot sell.
• Revenue and orders: whatever single figure the founder actually watches. One number, the same one every week.

Some of these numbers are checking an automation, not a person. If a Shopify Flow workflow holds orders on the wrong condition, nobody on the team made a mistake this week. The procedure that describes that workflow did.

Keep, re-record or retire

Here is the rule that makes this more than a status meeting. Every item ends in one of three decisions about the procedure behind it. There is no fourth option.

Retire is the option teams skip, and it is why SOP libraries fill up with documents nobody trusts. A procedure for a tool you stopped paying for is worse than no procedure. To a new contractor with no context, it looks official.

No owner and no date means no decision. The first item on next week's agenda is last week's actions, so anything without a name on it gets noticed seven days later.

That is the whole argument for doing it here rather than in a separate review. A standalone SOP review is the first meeting cancelled in a busy week. This one already happens.

Hearing drift in the room

A procedure that has drifted usually announces itself in normal conversation. Four things to listen for:

1. The same question gets asked twice. If the procedure answered it, nobody would ask.
2. Rework keeps landing on the same step. One step failing again and again is a documentation problem, not a discipline problem.
3. A tool underneath changed. "We moved to a new 3PL" is a sentence that should put a procedure straight on the list.
4. Someone new is doing the work. The procedure still names the person who handed it over.

The quickest check takes ten seconds. Look at the version number and last-updated date on the procedure. If it has neither, that is its own finding.

Where the decisions live

Not in the chat thread. Keep one decision log, with the owner and due date on every line, somewhere messages do not scroll away.

This matters more than it sounds if your team is on Slack's free plan. Slack hides messages older than 90 days on the free plan and permanently deletes them after one year. A re-record decision made in a channel in October can be out of sight by January.

Whatever you use, someone who missed the meeting should be able to find the decision. For anything too big for the 30 minutes, keep a parking list and give each entry an owner, so it gets its own time instead of eating the meeting.

Where this breaks

Three ways, and the third is seasonal.

It turns into status updates. Each owner reads out their week, the half hour is gone, and nothing gets decided. Keep the reporting short and spend the time on the one or two items that are actually stuck.

One person gets every re-record. Five updates agreed in one meeting hands someone a day of work they did not plan for. Two a week is a pace a small team can keep. Five is a wish.

Peak season breaks the owner list. If you staff up for the rush and shrink afterwards, the person who agreed in October to re-record the refund procedure may be gone by December. Reassign owners before peak, not during it.

This is where ReccordSOP helps. It makes "re-record it this week" a ten-minute job rather than a writing project: record the task once, and you get a step-by-step SOP with the clicked element highlighted on each screenshot. Record it again later and it compares the new run against the existing SOP, so you see exactly which steps changed. What it will not do is run the meeting or make the keep, re-record or retire call. That stays with the owner.

Book the recurring slot this week. List the five items and put exactly one name against each. Then run the first meeting with one rule: nothing closes until someone writes keep, re-record or retire in the log, with an owner and a date.