How Does a Hybrid Team See What Its Bots Are Doing?

The morning report is missing

A manager opens the shared folder before a hybrid team meeting. Yesterday's summary is there. Today's summary is not. The automation page shows an active schedule, and the last chat message says the bot completed its work. Neither tells the manager whether there is a usable report for this morning.

This is a coordination problem before it is a dashboard problem. The team needs to know what was expected, what actually happened and what someone must do next. A plain shared register can provide that information. A sophisticated display cannot repair a status label that means something different to every reader.

Start with the job's purpose. A daily service summary might be complete when a dated draft is saved for review. A customer notice might require review, approval and confirmed delivery. Those are different completion contracts. If both jobs display the same green tick after generating text, the team cannot rely on either.

The proposed method here is a lightweight management control. Its state names are recommendations, not standard labels guaranteed across AI products. Adapt them to the tools actually used, while preserving their meaning. Keep product events as evidence underneath the shared vocabulary so a reviewer can inspect the original record.

Describe the expected work before the latest activity

Give each job a stable identifier and each occurrence its own run identifier. The weekly supplier digest and this week's digest are related, but they are not interchangeable. A successful run from last Thursday does not satisfy this Thursday's expectation. Store the reporting period with the occurrence, not only in its filename.

Record the expected output in terms another person can check. For a digest, that might be a readable document containing the agreed sections and source references. Add the destination, intended audience and permitted action. A job authorised to prepare a draft must not be described as authorised to send it because sending would be convenient.

Define the due time and timezone explicitly. A hybrid team may have colleagues reading the record from different locations. Use the organisation's agreed operational timezone and show it alongside deadlines. Distinguish the scheduled start from the output deadline, especially where a review stage sits between generation and use.

Assign a business owner and an exception owner by role. The business owner defines what useful completion means. The exception owner handles the next problem. These can be the same role in a small team, but the record should make that choice visible. A named queue without a responsible role is another place for work to disappear.

Include a short validity rule. A report built from last month's source extract might be a valid historical document and an invalid input to today's decision. Record the source period and any freshness condition. This prevents a recent file timestamp from disguising old evidence or an empty rerun from appearing current.

Use states that require evidence

The first useful distinction is between planned and running. Planned means the occurrence is expected. Running means there is evidence that execution started. An enabled schedule is evidence of configuration, not proof of a particular start. If the expected start passes without an event, record that gap for investigation rather than inventing activity.

Waiting for approval means a specific human decision prevents the next authorised step. The record should name that decision and its owner. Blocked means another obstacle prevents progress, such as unavailable input or a missing output. Avoid using waiting as a reassuring label for every unexplained delay. An unknown cause remains unknown.

Generated means the candidate output exists at the recorded location. Verified means the checks required by the job's completion contract have passed against that version. Approved means an authorised person has permitted the specified next action. These distinctions allow a manager to see useful progress without implying that unfinished review has already happened.

Scheduled and delivered need their own evidence where the workflow includes external communication. A platform booking confirms a reservation, while a destination check confirms what actually appeared. For an internal drafting job, those states may never apply. Do not require unnecessary stages, but never collapse a required stage into an earlier one.

Failed, cancelled and intentionally skipped also deserve clear meanings. A failure is an unsuccessful attempt. Cancellation is an authorised decision to stop. A skip follows a defined rule, such as no eligible input. Retain the reason. Otherwise, a quiet day can be mistaken for a healthy service when no work was attempted.

Check what the product event actually means

Product behaviour matters when interpreting these records. Anthropic's Claude Code Desktop scheduling documentation distinguishes local tasks from cloud tasks. It documents that local tasks require the app to be open and the computer awake. It also describes permission-related stalls. These are documented behaviours, not tests performed for this article.

A shared record should therefore identify the execution location and relevant preconditions. A local task with a sleeping computer needs a different response from a cloud task with a rejected input. Do not diagnose either from a generic missed-run alert. Inspect the supported product record and keep the explanation provisional until the evidence supports it.

Treat the product's completion message as one input to the management view. Ask whether it means the model stopped, the process exited, a file was written or a delivery was confirmed. The answer determines which shared state can safely be set. If the product does not expose enough information, show that limitation openly.

This is also why a status summariser should not have authority to advance approvals. Its useful role is to organise supplied events and highlight contradictions. It can say a run reports completion while its expected artefact is absent. It cannot solve that contradiction by assuming the artefact exists somewhere else.

Three jobs, three different morning outcomes

Consider a fictional small Australian services business with colleagues working across home and office locations. It has three recurring jobs: a daily operations digest, a weekly supplier watch and a customer notice draft. All records, times and artefacts in this example are constructed. No automation was run to produce these outcomes.

The operations digest is expected at 08:30 Australia/Sydney. Its source manifest and a readable draft for the correct date are present. A reviewer checks the required sections and source links against the agreed scope. The constructed record moves from generated to verified. Because the contract ends at an internal verified draft, the job can close there.

The supplier watch is due at 09:00. Its run log contains a completion message at 08:52, but the expected weekly document is missing. The record does not turn green. It states that execution reported completion and output confirmation failed. The exception owner is the operations coordinator, who must reconcile the destination and run evidence.

The coordinator first checks whether the correct period and destination were requested. A retry is not the first action because the original run could have written elsewhere. In the constructed scenario, no artefact can be located in the approved destinations. The job remains blocked pending a controlled rerun decision, with the missing-output evidence preserved.

The customer notice draft exists, but the proposed service date conflicts with its source brief. The job waits for the service owner's decision on the date. It is neither failed nor approved. Its next action is to resolve the contradiction, revise the draft if necessary and repeat the content check before any sending decision.

At the meeting, the manager sees one verified internal output, one missing-output exception and one pending human decision. That summary is shorter than three transcripts and more useful than three activity indicators. It tells the team where coordination is required without speculating about why a colleague has not responded.

If the service owner later resolves the date, the change creates a new draft version. Earlier verification cannot automatically cover that revision. The record links the decision to the changed version and returns the item to review. The preserved history explains why a job moved backwards without suggesting that the system is malfunctioning.

Make the exception small enough to act on

An exception message needs a concrete subject. State the job and reporting period, the expected result, the observed gap and the owner of the next action. Include an evidence link with suitable access. A message saying automation needs attention leaves the recipient to reconstruct the problem before doing anything useful.

Separate observations from suggested explanations. Missing output is an observation after checking the agreed location. Permission failure is a diagnosis requiring corresponding evidence. A summariser can propose checking permissions, but it should label that as a next step rather than report it as the cause. The distinction protects both troubleshooting and accountability.

Choose escalation timing from the business consequence. A draft used next week does not need the same response as a missing input for an imminent service decision. Agree a response window and fallback owner before the first incident. If the owner is unavailable, use that route rather than repeatedly notifying the same person.

Avoid alerting on every routine event. A stable verified outcome belongs in the register or scheduled summary. A new blocker, overdue decision or contradictory completion signal may justify an interruption. This is a recommended design choice, not a claim about measured alert reduction. Review it against the team's actual experience after a bounded trial.

Keep visibility away from employee surveillance

The operational record needs evidence about bot work. It does not need keyboard activity, screen captures of employees, inferred effort or rankings of people by response speed. None of those fields explains whether a supplier digest exists. Exclude unrelated worker information at collection time instead of hoping a later summary will conceal it.

Even necessary logs can contain personal information. The Office of the Australian Information Commissioner's commercial AI guidance addresses suitability, human oversight and privacy across the AI lifecycle. The practical recommendation here is to use minimal operational references and controlled access, with privacy review for the actual implementation.

Use role labels in the shared view where they are sufficient. Keep detailed error material in an appropriately restricted evidence location. Do not paste customer messages or employee matters into a general team channel to demonstrate that a bot encountered them. A concise reference can direct an authorised reviewer to the original record.

Explain the register's purpose to the team. It supports coordination of machine-assisted work and its decisions. It is not a productivity scorecard for staff. If someone proposes reusing the data for performance management, treat that as a separate purpose requiring its own assessment and authority, not a minor dashboard enhancement.

Start with a view people can maintain

Build the first version around a small set of recurring jobs. Ask another colleague to identify the next action using only the record. If they cannot distinguish a missing output from a pending decision, improve the fields before adding more integrations. Useful visibility depends on understandable evidence, not the number of automated feeds.

Test the awkward cases deliberately with invented records. Include a stale last-success date, an unreadable output, a permission request and a duplicate completion event. Check that the summary preserves these distinctions. A normal successful run alone does not prove that the view helps when someone needs to intervene.

At the end of the trial, review false alarms and hidden gaps with the job owners. Change the completion contract when the work requires it, and version that change. Keep historical records under the rule that applied at the time. Otherwise, a revised definition can make past results look more complete than they were.

For managers, the useful question is whether the team can explain today's exceptions without opening every chat. For job owners, it is whether each status has evidence and a next action. Define completion first. Then make it visible. A reliable operations view lets people coordinate their work without turning their working day into a monitoring exercise.

Do this Monday

• Choose three recurring jobs and define each completion contract.
• Separate generated, verified, approved and delivered where they apply.
• Test a missing output and a pending decision using invented records.
• Assign an exception owner and an agreed escalation route.

Copyable starting point

Use the status record and exception-summary prompt that accompany this article. They include the complete constructed inputs and expected outputs.

Bot-work visibility: reusable materials

Status: authored templates and constructed teaching records. No bot ran and no person approved a real output in this exercise. All times use Australia/Sydney. Role labels are fictional.

Bot-work record

Job ID:
Run ID / reporting period:
Purpose and completion contract:
Allowed action / prohibited next action:
Execution location and known preconditions:
Scheduled start / output deadline / timezone:
Source period / freshness requirement:
Business owner role:
Exception owner role / fallback role:
Execution state / observed timestamp / evidence reference:
Output state / output version / evidence reference:
Verification state / checks / reviewer role / evidence reference:
Approval state / permitted action / version / authority reference:
Delivery state, if relevant / destination confirmation:
Current exception / observed fact / unconfirmed hypothesis:
Next action / action owner / response deadline:
Last checked / next check:

Use separate execution, output, review and delivery fields when one overall status would hide uncertainty. Unknown is a valid value. A role-based view still needs an internally identifiable accountable owner through the team's approved process.

Exact synthetic input

Scenario: invented small services business, 11 November 2026.
Time of snapshot: 09:10 Australia/Sydney.
D01 / D01-20261111 / daily operations digest.
Completion contract: verified internal draft for 11 November, required sections and source links.
Deadline 08:30. Allowed action: prepare and verify internal draft only.
08:10 run started: event E01.
08:20 draft v1 and source manifest exist: artefacts A01 and A02.
08:25 required sections and source links checked against scope: record V01.
Business owner: operations manager. Exception owner: operations coordinator.
No distribution or publication authority.

S01 / S01-20261111 / weekly supplier watch.
Completion contract: current-period document in approved weekly folder.
Deadline 09:00. Allowed action: draft only.
08:52 run reports complete: event E02.
09:05 output check: no current-period document in approved destinations, record X01.
Cause: unknown. No retry authorised yet.
Business owner: procurement manager. Exception owner: operations coordinator.
Next action: reconcile destination and run evidence; then request a controlled rerun decision if needed.

N01 / N01-20261111 / customer notice draft.
Completion contract: reviewed draft plus separate authorised sending decision.
08:40 draft v1 exists: artefact A03.
08:50 source date conflict found: review R03.
Service date unresolved. Service owner must decide; sending is not authorised.
Business owner and decision owner: service owner.
Next action: resolve date, revise if required, repeat content review.

Exception-summary prompt

Use only the supplied job contracts, event records, artefact checks and decision records.
Exclude worker activity, individual performance judgements, customer content, credentials and unrelated personal information.
For each run return: job/run ID, reporting period, execution evidence, output evidence, verification state, approval state, delivery state if applicable, exception, next action and owner role.
A schedule proves configuration only. A completion message alone does not prove an artefact exists. Generated does not mean verified. Approved does not mean delivered. Scheduled does not mean published.
Do not infer events from silence, resolve contradictory records or change an approval state. Mark missing evidence UNKNOWN and contradictions NEEDS OWNER RECONCILIATION.
Return one short team summary and one exception row per actionable issue. Separate observed facts from proposed diagnostic steps. Human owners confirm closure and any further action. Do not send messages or run jobs.

Expected constructed output

Team summary: One internal draft meets its verification contract. The supplier watch lacks the required output. The customer notice awaits a service-date decision. No external action is authorised by this summary.

Manual acceptance exercise

• Compare every summary statement to a supplied reference.
• Replace V01 with UNKNOWN and confirm D01 no longer claims verified completion.
• Add a last-success record from the prior week and confirm S01 remains unresolved for this period.
• Add a duplicate E02 event and confirm it does not become two successful outputs.
• Remove the decision owner for N01 and confirm the summary flags missing ownership.
• Confirm no fields describe keystrokes, attendance, inferred effort or performance scores.

These are proposed checks for a future implementation, not reported automated test results.

Related reading

• Managers Need an AI Operating Rhythm, Not More Pilots, on the management routine that a work-visibility record supports
• Run a Business Grok Bot While Your Computer Is Off, the companion article for 11 November

References

1. Anthropic: Schedule recurring tasks in Claude Code Desktop
2. Office of the Australian Information Commissioner: Guidance on privacy and the use of commercially available AI products