The customer is waiting. The virtual assistant has finished the checklist. The AI tool has produced a reply. The manager assumes someone else approved it.
A reporting chart can look complete while responsibility for a customer outcome remains unclear. When Australian staff, Philippines-based VAs and software contribute to the same process, the useful question is who can move the work forward, who can make each decision and who takes over when that person is unavailable.
Build those answers into a short operating chart alongside your reporting lines. The example below is a proposed structure for a service business, using fictional people and responsibilities you can adapt.
Put one person beside the customer outcome
Start with a result the customer can recognise: “The new customer receives an approved service schedule and knows what happens next.” Give one named human responsibility for seeing that result through.
That outcome owner needs authority to resolve competing priorities and obtain decisions from other teams. They do not have to perform every task or approve matters outside their competence. If technical or professional approval is required, allocate it to the appropriate authorised person.
The VA can own the daily process: keeping records complete, managing the queue, chasing decisions and identifying stalled work. Depending on their capability and authority, a VA or offshore specialist may also be the outcome owner. Geography does not decide responsibility.
The National AI Centre recommends assigning a senior AI governance owner and a specific accountable person for each AI system. That is a useful distinction: ownership of the business outcome and ownership of the software must both be visible. Read the AI adoption foundations.
Give each role a decision boundary
In this hypothetical team, Maya owns the onboarding outcome, Liza runs the process and Evan maintains its automation. The bot appears in the tool register; every responsibility below belongs to a person.
| Responsibility | Primary person | Named backup | Authority and expected result |
|---|---|---|---|
| Customer onboarding outcome | Maya, operations manager | Priya, service lead | Resolves priorities and confirms the customer receives the agreed next steps |
| Daily process and exception queue | Liza, VA coordinator | Noah, senior coordinator | Checks records, requests information and routes decisions; does not invent missing approvals |
| Service scope and delivery commitment | Priya, service lead | Maya, within her documented authority | Approves scope and dates supported by actual capacity |
| Automation configuration and recovery | Evan, systems lead | Renee, trained systems administrator | Maintains access, investigates failures and restores a tested workflow |
| Release of routine customer messages | Liza, within an approved procedure | Noah, under the same procedure | Checks the source, recipient and approved commitments before sending |
These are role assignments, not necessarily five full-time jobs. One person may hold several roles in a small business. Keep each decision boundary explicit even when the same name appears twice.
Backups need the relevant training and delegated authority. A contact name alone does not authorise someone to approve a discount, promise delivery or change access permissions.
Make handovers show what is still undecided
Agree a small set of fields for every open item: customer reference, current stage, next action, action owner, due time and the evidence needed to finish it.
Add a separate decision field when a coordinator is waiting for approval. “Ready for service-lead review” should remain distinct from “approved for customer release”. A completed checklist may establish that information is present; it does not settle an unresolved commercial question.
For each bot, record its permitted inputs and actions, the person who supervises it, the human who can change its configuration and the route for failures. Describe the actual permission: “prepare a draft from approved schedule fields” is clearer than “handle onboarding”.
The tool owner should also arrange review of permitted information and access. The OAIC advises assessing product suitability, privacy and security risks, human oversight and who can access information. See the OAIC's commercial AI guidance.
Walk an exception through the chart
Suppose a new customer requests priority delivery that their agreed package does not include. An AI drafting tool reads an old sales note and proposes: “We have included priority delivery at no extra charge.” No person has approved that commitment.
Liza checks the proposed message against the current agreement and stops its release. She records the mismatch, links the relevant records and assigns the scope decision to Priya. She can acknowledge the request without promising its outcome.
Priya checks capacity and confirms the available options. Maya resolves any competing priority affecting onboarding. Liza then sends wording that reflects the recorded decision and updates the next action. If the customer must choose an option, the item remains open until that response is handled.
Evan investigates why the obsolete note entered the drafting step, pauses affected drafts and checks whether other queued messages have the same problem. Maya decides whether the customer outcome needs further action, while Evan is responsible for the software correction. Neither task disappears because someone clicked “reject”.
Plan the absence before it happens
Agree when a backup takes over and record the transfer. While Liza is away, Noah owns the daily queue. If Maya's outcome responsibility transfers to Priya, show the start and end of that delegation so colleagues know whose decision applies.
Practise one handover using an unfinished request. Can the backup find the evidence, understand the pending decision and contact the right person without using someone else's login?
Include a manual route for important work when automation fails. The National AI Centre recommends suitable human oversight, intervention points and alternative pathways for critical functions. See its human-control guidance.
Keep the chart attached to real work
At the next team review, choose one delayed request and follow it through the assignments. Look for decisions with no owner, backups lacking permission and software changes nobody was responsible for checking. Update the chart when roles or processes change.
For the wider operating model, read our guide to local expertise, Filipino talent and AI. To define a VA role around a specific process, talk to Nexus about the work, decision rights and support that role needs.
