Time Tracking for Virtual Assistants: 9 Buyer Tests

A virtual assistant's hour has three audiences.

The assistant needs a record they can inspect and correct. The agency needs an approved record it can use for pay, capacity, and job costing. The client needs a deliberately narrower account of the work performed for them.

Those views share an origin, but they should not expose the same fields or use the same denominator. A client does not need another client's task names. A payroll reviewer should not have to infer paid time from a screenshot count. An assistant should be able to challenge a wrong client code without rewriting history.

That is the buying problem. It is larger than starting a timer.

Before an agency chooses time tracking software for virtual assistants, it should make one awkward hour survive nine tests. The tests below turn a polished demo into an acceptance decision.

Evidence note: this is a desk review, not a production test. The linked vendor and authority documentation was rechecked on 9 September 2026.

Start with one hour and three views

Call this the One Hour, Three Views rule.

The product passes only when the agency can derive all three without maintaining a secret spreadsheet beside it.

Here is the short buyer matrix. Run the detailed tests with real roles and test data, not an administrator clicking through an ideal path.

Test 1: write the record contract before configuring the tracker

The first configuration belongs in a policy, not a settings screen.

Define which time is paid, which time is billable, what belongs to a retainer, what remains an agency cost, how breaks are treated, how small client interruptions are recorded, and who settles a disputed category. A timer can apply those decisions. It cannot make them fairly.

The essential relationship is:

Approved payable hours = approved client-billable hours + approved agency-paid non-billable hours

That second term can include internal meetings, training, agency rework, paid breaks, or business development. The exact categories depend on the contract and local law. The important point is that they exist.

Fixed-fee and retainer work needs the distinction too. Tracked time can show delivery cost, remaining capacity, and workload without becoming the client's invoice formula. The judgement stays yours: you set the denominator.

A time tracker should not be the agency's worker-classification decision-maker. Settle the engagement question outside the tool, then configure only the approved pay, billing, and record rules. If the agency is hiring across countries, make that decision alongside the wider choices in this guide to managing offshore teams.

Pass this test when a new assistant can categorize five sample activities the same way the payroll reviewer and account manager do.

Test 2: model identity, clients, and roles without shortcuts

A virtual assistant agency is a many-to-many system. One assistant may serve several clients. One client may receive work from several assistants. A team lead may review people across accounts while an account manager sees only selected clients.

Build that shape during the trial:

1. Create two assistants, two clients, an internal project, a team lead, a payroll reviewer, and a client viewer.
2. Give one assistant access to both clients and the other to only one.
3. Record different internal pay and external billing treatment without exposing either rate to the wrong role.
4. Archive a client and move an assistant between teams.
5. Sign in as every role and record the actual visibility.

Current time-tracking systems model this differently. Toggl Track's time-entry documentation lists dates, duration, descriptions, tasks, projects, tags, and billable state. That can be a workable structure, but the buyer still has to prove it matches the agency's account model.

Do not accept “role-based access” as an answer without the role test. Ask the vendor to show the least-powerful role that can approve an assistant, export payroll, view a screenshot, change a billable rate, and open a client report.

Test 3: force rapid client switching and uncoded time

Virtual assistant work rarely arrives in tidy two-hour blocks. An inbox reply for Client A interrupts calendar work for Client B. An internal Slack message sits between them. A five-minute account check becomes a thirty-minute repair.

Run that sequence with a timer. Then inspect what happens when the assistant starts the next entry without a client, resumes a previous task, changes the code later, or records the work manually.

The pass condition is not maximum detail. It is stable, useful detail:

• client and project are required where the commercial policy requires them
• an internal code exists for paid non-client work
• uncoded time enters an exception queue instead of inheriting the last client silently
• manual time is labeled as manual
• rounding rules are visible and consistent
• task descriptions can be rewritten into a client-safe report without revealing internal discussion

If the pilot still needs a spreadsheet, invoice note, or task board to explain what the tracker did not capture, record that as a product failure signal. The agency should not need two conflicting sources of truth just to tell a client where their hours went.

Test 4: cross midnight, lose the connection, and change time zones

“Offline mode” is not a yes-or-no feature. The useful questions are what works offline, which context disappears, how conflicts resolve, and what happens before synchronization finishes.

Current documentation makes the difference visible. Clockify says its Windows app can store offline entries for later sync, but projects, tasks, and tags are unavailable offline, and unsynced entries can be lost if a user logs out. Jibble documents a different edge: offline events can conflict with manager-added online events, and the conflict is marked for resolution rather than both events being calculated.

Test a shift that begins at 11:40 p.m. in the assistant's timezone, loses connectivity at 11:55, crosses midnight, and reconnects after a manager has added a missing clock-out. Repeat it across a daylight-saving transition if any client or reviewer uses one.

The resulting record should state:

• the assistant's local timestamp and timezone
• a stable instant such as UTC for ordering events
• the workday and pay-period rule used by the agency
• whether the event was online, offline, manual, or manager-added
• the conflict and the person who resolved it
• the client and task code, even if that context had to be added after reconnection

Reject a system that silently chooses the browser, device, organization, or viewer timezone and then changes the workday depending on who opens the report.

Test 5: make a correction without making history disappear

The worker record needs a correction path because people choose the wrong client, forget to stop a timer, work through an approved interruption, and notice mistakes after submission.

A correction is trustworthy when the original value remains available, the new value is explicit, the actor and timestamp are preserved, the reason is recorded, and the entry returns to the right review state. A manager's ability to fix an entry does not justify an invisible overwrite.

Test three changes:

• the assistant corrects an unsubmitted client code
• the assistant requests a duration change after submission
• an administrator repairs an already approved entry

The agency should be able to answer which totals changed downstream. Did payroll update? Did a client report update? Did an exported invoice remain stale? Did approval reopen?

An activity history is stronger than a final value. Require the pilot record to show the changed field, original value, new value, actor, reason, timestamp, and any downstream approval or export state. Treat that level of traceability as a buyer requirement, not as a reason to assume every product behaves the same way.

Test 6: prove that approval changes the state of the record

Approval should create a boundary between recorded time and accepted time. If nothing locks, routes, or reopens, the green approval badge is decoration.

Picture a 12-person property-management support agency during a five-day pilot. This is a labeled hypothetical, not KordanoTime customer data. One assistant submits a clean week, one uses the wrong property account, one forgets a break, and one sends an entry to the wrong reviewer.

The system should let the reviewer approve the clean entries, reject or return the exceptions with reasons, preserve the submitter's visibility, and keep unapproved time out of payroll and client billing. It should also name the administrator-only repair path after a lock.

Approval products vary. Teamwork documents a submit, review, approve, and reopen workflow in which approved timesheets are locked for the submitter. Intuit's QuickBooks Time guidance likewise says an approved timesheet must be unapproved before its time can be edited or deleted. These examples prove why a buyer must test state changes instead of accepting an approval badge.

The buyer's job is not to prefer one interface. It is to document the exact state sequence the agency needs:

Recorded → submitted → returned or approved → exported → corrected and re-approved

No downstream step should treat “submitted” as “approved.”

Test 7: reconcile pay and client billing without forcing equality

Now give the pilot a deliberate mismatch.

The assistant records seven payable hours: five hours of client delivery, one hour of internal training, thirty minutes of an agency meeting, and thirty minutes of paid non-client administration. The client contract bills only the five delivery hours.

The correct result is not a discrepancy. It is two valid totals from one approved record:

If the agency charges a fixed fee or monthly retainer, the invoice amount may not be an hours-times-rate calculation at all. The hours still support capacity, scope, and cost decisions.

For US employees covered by the FLSA, Department of Labor guidance says records must include accurate employee, hours-worked, and wage information, although no single form is required. Other countries and contractor arrangements have different rules. Get jurisdiction-specific payroll and employment advice; a client report is not a substitute for the required employment record.

The final artifact should be a Three-View Hour Receipt with the source event, client code, payable category, billable category, correction state, approver, export identifier, and safe evidence policy. It should reconcile the views without pretending they are identical.

Test 8: set the evidence boundary before enabling screenshots

A time record can answer when a person recorded work. It does not prove that the work was good, that the task was necessary, or that a high activity number created client value. That distinction matters when a vendor offers screenshots, app activity, mouse or keyboard activity, or screen recordings as “proof.”

Start with purpose. Is the agency settling an hourly dispute, meeting a client contract, supporting a new-hire review, protecting sensitive systems, or merely trying to feel less uncertain? Each purpose can justify a different, narrower record. The broader habit of judging work by visible activity is how productivity paranoia begins.

For every evidence type, record:

• why it is collected
• whether a less intrusive record would work
• when collection starts and stops
• what the assistant can see, challenge, blur, or delete
• which internal roles can view it
• whether a client can view it and for which project
• how long it remains available
• what happens to the associated time if evidence is removed

This is both a trust and risk decision. NIST's voluntary Privacy Framework treats privacy as an organization-wide risk-management responsibility rather than a single security setting. It is not law, so the agency still needs advice for each worker's jurisdiction. The larger operating principle travels well: collect evidence for a named purpose and expose only what that purpose requires.

Screenshots deserve an awkward-content test. Use test captures to prove who can delete one, whether deletion is reversible, what marker remains in the time record, and what happens to any shared link. A buyer needs to know its own tool's exact result before a password, health record, customer conversation, or another client's screen appears.

NIST's voluntary Privacy Framework gives a useful vendor-review sequence: identify the processing and parties, set privacy requirements and target outcomes, assess the risks, and verify that the requirements are met. Do not stop at “encrypted.” Ask about access, tenant boundaries, links, deletion, retention, subprocessors, and exports too.

Test 9: leave with a usable record and closed access

The exit test belongs in procurement because it is easiest to ignore before the agency has years of payroll and client history inside the product.

Export one complete test period. Include raw events, approved time, client and project codes, billable state, pay category, notes, edits, approval history, evidence references, and stable identifiers. Then verify that another system or a careful reviewer can rebuild the totals.

A summary PDF is useful for a client. It is not a complete agency archive.

Do not accept “export available” without inspecting the file. Check whether the export preserves raw events, projects, clients, billable state, notes, edit metadata, offline state, timezones, schedules, and payroll fields, then rebuild the pilot totals from it. A summary that cannot reproduce the approved record is not an exit path.

Finish by removing the client viewer, archiving the assistant, revoking a manager, and requesting deletion of test captures. Record which data remains for contractual or legal reasons, which disappears, how long links survive, and who can confirm the change.

For a deeper vendor exit review, use the ownership questions in Who Controls Your Workforce Data?.

Run the nine tests as one five-day pilot

Feature checklists encourage buyers to accept nine isolated yes answers. A pilot should prove the chain.

Use one week, two assistants, two clients, one internal project, two reviewers, and one client viewer. Include ordinary entries, client switches, a manual correction, an outage, a midnight boundary, a rejected entry, paid non-billable time, and sensitive test content that must remain hidden.

At the end, make one of three decisions:

• Adopt: all three views reconcile, permissions hold, exceptions are visible, and exit is usable.
• Repair: the product can work, but policy, roles, client structure, or integrations need named changes before rollout.
• Reject: a silent failure can alter pay, expose another client, erase a correction, or trap the record.

This is the same discipline behind the broader questions to ask before buying time tracking software, narrowed to the commercial reality of virtual assistant agencies.

Where KordanoTime fits

KordanoTime's owner has committed to a December 1, 2026 first release. The planned scope includes online and offline time tracking with a daily timeline; schedules, attendance, breaks, leave and approvals; payroll integrations or payroll-ready exports; QuickBooks or more than 60 integrations; screenshots and screen recording; office-versus-remote reporting; multiple currencies; admin impersonation controls; and custom subdomains. The product is pre-launch, and working-product and deployment QA remain pending. Use the nine tests above against a working build before adopting it.

The planned Early Access allowance is 500 screenshots per team each month, with video screen recording. The planned Team tier includes unlimited screenshots. The owner has also committed to free, unlimited, human-assisted migration of projects, users, work history and other available old-product records. Migration operational readiness still needs verification before onboarding.

The planned default for Kordano-managed screenshot and recording media is Cloudflare R2, which encrypts stored objects and metadata with AES-256; the planned media path uses TLS in transit. Inspected pre-launch screenshot viewing requires a signed-in viewer with the view-screenshots permission, organization scope and target-visibility checks. Clear screenshot links expire after five minutes; when screenshot blur is enabled, blurred images use an authenticated, permission-checked route. These inspected controls do not establish equivalent recording-viewer behavior, and working-product and deployment QA remain pending. The planned bring-your-own storage option covers screenshot and recording media only, using Amazon S3 or Cloudflare R2, not the product database.

GPS, geofencing, and employee-location features are planned for a 2027 release. They sit outside the December 1 first-release scope.

Review the KordanoTime trust model and use the nine tests above as the acceptance sheet. The point is to keep the right record for each decision.