Skip to content

Product Roadmap — Beating QuickBooks Time (research-backed)

Internal planning doc. Goal: make QBTime Manager the daily one-stop shop for QuickBooks Time (QBT) management, so admins/managers rarely (ideally never) open the original QBT app. This captures researched user complaints about QBT, what our API access actually lets us fix, and a recommended build sequence.

Researched June 2026. Sources at the bottom.

Can we be a true "never log into QBT" one-stop shop?

Partially — and the ceiling is the QBT REST API, not our effort.

We talk to QBT via stored per-company service tokens (rest.tsheets.com/api/v1). Anything that API exposes, we can surface in our app: users, schedules, timesheets, jobcodes, geolocations, current-totals, notifications, time-off entries, and the approval watermark. That covers the manager/admin daily workflow almost entirely — which is exactly our audience (we have no employee logins).

Two hard walls we cannot cross:

  1. Employees still clock in/out in QBT's own apps. There is no API to be the punch clock — that is QBT's core product. We manage the data; we don't replace the time capture.
  2. Anything outside the REST API stays in QBT — account/billing settings, the geofencing configuration UI, payroll, and some admin toggles.

Honest positioning: "Managers run their whole day in QBTime Manager; employees still punch in QBT." That is achievable and compelling — not a 100% platform replacement, but a complete management cockpit.

Researched complaints, mapped to API feasibility

Tier 1 — we can fix these BETTER than QBT (buildable, high value)

  • Multi-level / sequential approvals. The most-cited workflow gap. QBT only supports single-person approval. Feasibility note: QBT's API models approval as a single approved_to / submitted_to timestamp watermark on the User object — not a per-timesheet record or a multi-approver chain. So we build the workflow (manager → senior → done, audited) in our own tables and write the final approved_to watermark back to QBT only when our chain completes. This is our strongest differentiator because QBT structurally cannot do it.
  • Mobile time-off approve/deny. QBT cannot approve/deny PTO on its mobile app. Our app is already responsive — surfacing time-off entries with approve/deny on a phone directly beats them.
  • Reporting depth. Competitors win on this; QBT's reports are shallow and tier-gated. We already have a reporting engine + report-configs + snapshots — richer, saved, comparative reports are a natural extension.
  • PTO / leave visibility & balances. Segmented and clunky in QBT. We can read time-off entries and present a clean balances + team-leave-calendar view. API risk: the exact time_off/time_off_requests endpoint field shape was NOT confirmed in research — verify against the live API docs or a test account before committing.
  • Proactive alerting. QBT is passive. We already ship notification delivery; extending it (approaching overtime, missing punches, no-shows, real-time coverage gaps) is a clear "QBT never tells you, we do" win. Lowest risk — builds on shipped code, no new API surface.

Tier 2 — we can mitigate, not fully own

  • GPS sticking to a wrong location. We read /geolocations but can't fix QBT's GPS engine. We can flag anomalies ("this punch's location looks stuck or implausible"), which is more than QBT does.
  • Slowness / crashes on large data. Our "pull once, generate many" + KV caching already sidesteps some of this; a snappy UI over the same data is a felt win.

Tier 3 — outside the API (do NOT promise these)

  • High pricing — Intuit's; our app adds cost, doesn't remove it (though consolidating tools may net-justify it).
  • Payroll being a separate subscription — payroll isn't in the time API.
  • Employee punch experience / app stability — employees still use QBT's clock apps.

Ordered by risk and leverage, not just appeal:

  1. Proactive alerts expansion — ✅ SHIPPED 2026-06-03. No-show, late, missing-punch, and coverage-gap alerts derived from the per-run attendance result, written to the bell, with per-company on/off prefs (Settings page, company_alert_prefs, migration 0006). Channel defaults to bell; email is a documented follow-up.
  2. Multi-level approval workflow — ✅ SHIPPED 2026-06-03. approval_requests
  3. approval_steps (migration 0007), sequential 1- or 2-level chain, approve/reject per step, on final approval writes approved_to back to QBT (best-effort: no-ops if the Approvals Add-On/token is absent). Approvals page + menu item. Audited.
  4. PTO / time-off management — ⚠️ READ-ONLY SHIPPED 2026-06-03. The Time Off Request object's exact field names could NOT be confirmed from the public docs (the section didn't render in fetch), so the read layer (timeoff.ts) is DEFENSIVE — normalizes across plausible field variants — and approve/deny write-back is DEFERRED until the QBT trial confirms the real payload. Time Off page + menu item ship the visibility win now.
  5. Reporting depth — ✅ SHIPPED 2026-06-03 (all types wired; some ASSUMED). runReport now dispatches by report_type across a 27-type catalog: Hours, Overtime, Missing-punch, Weekly timesheet, Detailed timesheet, Pay-period and saved views are verified; Hours-by-jobcode, Labor-cost, Pay-period, Schedule-vs-actual, On-the-clock-now, GPS, and Edited-timesheets are built + emailable on ASSUMED QBT fields (flagged in code, the config UI, and an in-email banner). Generic table template + per-type dispatch shipped. Verify the ASSUMED field mappings at the QBT trial before trusting those numbers. Tier-1/2/3 additions (payroll summary, wage, job costing, PTO balances, break compliance, certified payroll, ACA, hours-by-group, approvals-history, audit log) are built + emailable; the pay-rate/break/group/PTO ones are ASSUMED pending the trial. Comparative (period-over-period) reports remain a future enhancement.

API unknowns to verify before building the dependent features

  • [ ] Time-off endpoint shape — does the API expose time_off_requests with approve/deny fields, or only time-off entries that become timesheets once approved? Gates the PTO feature. Check tsheetsteam.github.io/api_docs + a test account.
  • [x] Writing approvals — CONFIRMED: approved_to is set via a Users PUT (requires the Approvals Add-On). Used by the shipped approval write-back.
  • [ ] Time-off field shape — STILL UNVERIFIED; the read layer is defensive and write-back is deferred until a QBT trial confirms the payload.

Sources