A protocol for measuring interruptions during the bookkeeping close

Freeze the scheduled task list for one close process and a defined sequence of periods. Every scheduled task instance remains in the population, including tasks with no interruption. This prevents an event-only log from hiding the uninterrupted denominator.

For this study, an interruption begins when active work stops because of an unplanned request, access failure, unavailable record, system incident, or decision dependency. It ends when work resumes or the task moves to another declared state. Scheduled handoffs, planned review waits, weekends, and prerequisites already represented in the close calendar use separate status codes. The definitions must be fixed before anyone sees period comparisons.

For each interruption, retain the task ID, category, stop time, resume time, initiating dependency, and resolution state. Avoid message bodies, screenshots, keystroke capture, or continuous monitoring. Preparers should be able to correct an accidental timestamp while preserving an edit history.

The BLS time-diary method is useful here only as a precedent for chronological episodes and coding. It does not validate these categories or imply that diary entries measure productivity. GAO's control principles support a defined objective and reviewable information, while the NIST Privacy Framework supplies a reason to assess the privacy consequences of person-level logging. The protocol is an OffshoreBookkeepers.com design built from those bounded ideas.

Report interruption events per scheduled task and nonoverlapping interrupted minutes. If two blockers overlap, count both categories as events but count the elapsed interval once in total interrupted time. State whether elapsed time uses calendar hours, staffed hours, or another convention, and define treatment of overnight spans before calculation.

Keep total wall-clock task duration separate. A task can remain open overnight without being actively interrupted, and a short task can have several diversions. Show counts, medians, and a distribution by predeclared category; do not rely on a single average. Missing stop or resume times should appear as data-quality exceptions rather than imputed precision.

A reviewer should sample both interrupted and uninterrupted tasks, compare their status histories with the event log, and test the planned-versus-unplanned distinction. Changes to the close calendar or category guide should be versioned. Access to identifiable logs should be limited to a stated purpose and period, with aggregate reporting used where it meets the need.

Preparers may enter events, but the close owner should approve the task population and category definitions. An independent reviewer should test coding and calculations. Employment decisions and individual productivity scoring sit outside this protocol.

Transaction volume, account complexity, close scope, system outages, deadline changes, and escalation assignments can alter the observed load. Logging may also become more complete over time, making a later period look worse even when work conditions did not deteriorate. These are alternative explanations to investigate, not proven causes.

Manual logs miss brief diversions and may round times; system histories show status changes but not necessarily attention. Small populations make category comparisons unstable. Any report should disclose task coverage, recording method, missing events, privacy controls, overlap rules, calendar changes, and exceptional incidents. No universal threshold follows from this design.