The team has answered messages, updated records and run automations all week. Everyone has been busy. Yet the director still cannot tell which customer jobs moved forward, why older work remains open or what should change next Monday.
A weekly operating review turns those questions into decisions. It gives your Australian staff, offshore assistants and process owners a shared view of accepted work, delays and the capacity available next week. AI can help prepare a summary, but the meeting needs people who can check the evidence and authorise changes.
Here is an original 30-minute format for one workflow. Start small enough that participants can understand the work behind the numbers.
Prepare one page before the meeting
Choose a consistent reporting window and time zone. Record the workflow, its acceptance rule and the date the figures were extracted. “Completed” should mean the agreed result was accepted, rather than a task merely being moved into a done column.
The VA or coordinator prepares a compact page containing accepted work, open-job age, corrections, available capacity, customer feedback and last week's actions. Link to the source records so a reviewer can check a disputed figure without rebuilding the entire report.
Include the counts behind percentages and identify sampled measures. Four defects in twenty inspected records should not quietly become “20% of all work was defective” when hundreds of records were never inspected. Mark missing evidence as unknown and assign someone to resolve it.
Our VA and AI operations KPI guide provides definitions for a starting scorecard. Keep those definitions stable across weeks, or explain a change beside the results. Otherwise the review may celebrate a reporting change as an operational improvement.
Use the thirty minutes to make decisions
Invite the workflow owner, the colleague coordinating the queue and anyone needed for a specific decision. Seek written input from other contributors when attendance would add cost without helping the decision. Circulate the one-page review before the call.
| Minutes | Review question | Decision to record |
|---|---|---|
| 0–5 | What happened to last week's actions? | Close with evidence, revise or escalate |
| 5–12 | Which accepted results and aged jobs matter? | Set recovery priorities and owners |
| 12–18 | What caused corrections or customer friction? | Choose the issue worth investigating |
| 18–23 | Can next week's capacity meet the work? | Adjust coverage, scope or commitments |
| 23–27 | Which small process change will we test? | Approve one bounded experiment |
| 27–30 | Who will do what, and by when? | Confirm actions and the next check |
These timings are a suggested agenda, not a performance benchmark. If an issue requires a longer technical discussion, give it an owner and a separate session. Do not spend the remaining meeting trying to redesign a system while urgent work remains unassigned.
Read the queue as well as the totals
A rise in completed work can coexist with a growing collection of difficult cases. Examine the oldest unresolved jobs and identify what they are waiting for: customer evidence, an internal decision, technical review or available processing time.
Keep an unresolved customer's full waiting time visible even when the current delay is outside the VA's control. Separately record the reason for the wait. That supports a fair discussion of where the business can act without hiding the customer's experience.
In a fictional review, the team accepted 96 handover packs this week, compared with 88 last week. However, five older packs still await the same technical decision. The useful response is to assign an authorised reviewer and agree a next contact time, not simply praise the higher total and move on.
A solar administrator can organise the evidence and track that decision. The weekly meeting does not transfer technical sign-off to someone who lacks the required authority. Use the human exception queue guide to keep such blocked cases visible between reviews.

Investigate rework without turning the meeting into blame
Select a small number of representative corrections and trace the sequence. Was the source wrong, the instruction unclear, the AI draft unsupported, or the review skipped? Ask the people doing the work to explain what they could see at the time.
Discuss the process using the minimum necessary customer information. Link to restricted records when detail is needed rather than pasting private conversations into a widely shared meeting pack. Give people a separate route for sensitive concerns.
Customer feedback can reveal problems that throughput misses. A fast reply that contradicts an earlier promise may create more work. Record the underlying concern, what happened next and whether the customer still needs a response.
The National AI Centre's implementation guidance recommends monitoring system performance and feedback, regular review and human oversight. This weekly meeting is one proposed business practice supporting that work; it does not replace technical testing or a broader AI governance process. Read the National AI Centre's guidance.
Match next week's commitments to usable capacity
Start with actual availability, including planned leave, training and time reserved for review. Then estimate the volume and type of work due. Ten routine updates and ten disputed handovers are not interchangeable simply because both count as ten tasks.
Check the specialist or manager who approves the work as well as the assistant preparing it. Increasing preparation can enlarge a waiting queue if review capacity remains unchanged. Decide whether to rebalance work, arrange authorised cover or change a commitment before promising additional output.
If AI has reduced drafting time, ask where that time is now used and whether checking or corrections increased. The National AI Centre's ROI guidance distinguishes measurable value from activity and includes indirect costs such as training and governance. Read its return-on-investment guidance.
A shorter task is useful evidence, but it is not automatically a cash saving. Record the capacity released and the additional accepted work, customer support or other useful activity it enables.
Leave with one experiment and named actions
Choose a change connected to the problem observed. If missing source references cause repeated returns, test a clearer mandatory checklist on a small, suitable group of jobs. Keep the existing acceptance standard so the comparison remains meaningful.
Write a short experiment record: the problem, proposed change, owner, eligible work, measure, stop condition and review date. A limited test might show whether colleagues can use the change; it does not establish a universal productivity result.
Close the meeting by reading back each decision. Give every action one accountable owner and a dated check. At the next review, ask what happened and inspect the evidence before selecting another experiment.
Talk to Nexus about a weekly operating review built around your actual workflow, customer commitments and available decision-makers. A useful meeting should leave the team clearer about the work it will finish next.



