INVESTOR Q&A
The questions investors ask most — and our answers.
A prepared reference aligned with the deck: the thesis, product, privacy posture, competition, model, and ask, answered the way an investor would ask them.
THE THESIS & MARKET
What is TAB@Work in one sentence?
TAB is execution infrastructure for AI-native organizations — a horizontal coordination and recovery layer that detects where work has stalled across teams, systems, and agents, and routes recovery to whoever is best positioned to act, without replacing existing workflows.
What problem are you solving, and why now?
SaaS gave every team its own tool but never gave the organization a way to execute across them. Work stalls at the handoffs — between people, systems, and now AI agents. AI is multiplying what each tool can do, which widens the seams and compounds the cost of dropped handoffs. The bottleneck has shifted from intelligence to the infrastructure required to act on it. Every company is becoming AI-native; almost none are execution-ready.
How big is the market?
The Digital Employee Experience (DEX) market is projected to grow from $1.32B (2023) toward $2.97B by 2031, with Gartner projecting enterprise adoption rising from 15% to 50% by 2027. Underlying demand is larger: Gallup reports global employee engagement at 20%, an estimated ~$10T in lost productivity. TAB targets the execution-recovery layer beneath DEX — the infrastructure that turns that productivity loss into recovered work.
PRODUCT & ARCHITECTURE
What exactly is the product?
A horizontal coordination and recovery layer that sits alongside leadership, managers, employees, enterprise systems, and AI agents — replacing none of them. It has a fixed core engine (observation logic, breakdown detection, recovery orchestration, continuity model) expressed through adaptive wrappers tuned to each team’s tools, language, permissions, and rhythm. The infrastructure stays constant; the operating layer adapts.
How does the recovery loop work?
A closed loop, not a dashboard: (1) Observe the operational context where work already happens — tools, roles, handoffs, status. (2) Detect the exact breakdown — the specific point where execution stalled, as an event not a score. (3) Trigger the lowest-friction recovery — route the smallest action that unblocks work to the right actor, in-flow. (4) Return work with continuity — context, status, and next step preserved across systems. Each recovery trains the layer; recurring breakdowns surface as structural patterns.
What's the technical architecture?
TAB connects to the tools where work already lives — ticketing, CRM, communication, project management, internal databases — through standard APIs and connectors. It reads the signals of work in motion (task states, handoff timestamps, status transitions) to build a handoff graph, detects friction events against that graph, and routes recovery through the systems and people already in place. It is a read-and-route layer over existing systems, not a system of record.
PRIVACY, SECURITY & TRUST
How do you detect a friction event without surveillance?
The unit of measurement is the friction event — a stalled handoff, a reopened ticket, a missed transition — not a person’s behavior. Recovery is triggered by aggregate, system-level patterns: "this workflow stalled at this handoff," not "this person is underperforming." There is no sentiment detection, no burnout scoring, and no individual behavioral profiling. That is enforced by the architecture, not by a privacy policy that can be revised later — "anonymous by architecture."
How do you secure enterprise data?
TAB processes the signals of work in transit to detect execution gaps; it does not store the contents of workflows. It reads task states, handoff timestamps, and status transitions — not message bodies, documents, or conversations. Access is scoped per integration, encrypted in transit and at rest, and governed by the customer’s existing identity and permissions. TAB never acts outside the permissions of the account it connects through.
Does TAB monitor employees?
No. TAB watches the seams between systems and roles, not the people inside them. People are positioned as the recovery path, not the subject of surveillance. This is a deliberate design choice and a market differentiator: organizations can adopt AI through trust rather than monitoring.
How does TAB avoid alert fatigue?
TAB does not add another notification stream. It bypasses alerts by acting through the right channel — routing recovery to the role, system, or agent that owns the next step in the workflow, based on the handoff graph it builds from existing tooling.
COMPETITION & DIFFERENTIATION
How is TAB different from automation platforms (Workato, Zapier, n8n)?
Automation platforms move work between systems on a predefined trigger. They don’t detect when execution has stalled, and they can’t recover a handoff that fell through the seams. They handle the repeatable path you already mapped; TAB recovers the unplanned, ambiguous, cross-system work that no automation was built for.
How is TAB different from AI assistants (Copilot, ChatGPT, Claude)?
Assistants generate inside a single conversation but don’t hold the organizational context around the task — the permissions, roles, and handoffs where work disappears. TAB operates at the layer beneath the conversation: it carries the context across systems and actors, so recovery happens in-flow with continuity preserved.
How is TAB different from employee monitoring / productivity tracking?
Monitoring watches people to measure effort. TAB measures friction events, not people — aggregate and anonymous by design. The two are categorically different: one optimizes for observation of individuals; the other optimizes for recovery of work. They cannot be built on the same architecture.
What is the moat?
The handoff graph. Every recovery trains the layer, so recurring breakdowns surface as structural patterns and the system gets smarter about an organization’s specific seams over time. Combined with the fixed-core / adaptive-wrapper architecture, this creates compounding, environment-specific switching costs: TAB becomes the continuity layer an organization relies on to execute across its existing stack.
BUSINESS MODEL & GO-TO-MARKET
What is the business model?
Enterprise SaaS with per-environment licensing. TAB lands on a single broken workflow (no fee, design partnership), proves the loop, then expands to adjacent handoffs within the same organization. Pricing scales with the surface area TAB recovers — per environment, not per seat — which aligns our revenue with the value delivered and avoids the seat-count friction of traditional SaaS.
How do you land and expand?
Land through a single workflow where execution stalls most visibly — customer ops handoffs, IT change governance, or data pipelines. Map the handoffs, prove recovery, then expand across adjacent teams and systems using the same core engine with a new adaptive wrapper. The same infrastructure, re-expressed per environment, keeps expansion cost low.
What's the go-to-market motion?
Design-partner-led. We enter live enterprise environments with 3–5 design partners across customer operations and AI transformation, validate breakdown detection and recovery, and turn that evidence into a repeatable deployment playbook.
TRACTION & TEAM
What traction do you have?
A US design partnership embedded in a trading workflow; call-center field research focused on extreme early attrition and the operational friction behind it; and behavior-first AI prototypes testing intervention timing, trust, and low-friction recovery. We have catalogued 11 friction event types and mapped 40+ operational workflows. Pilot KPIs are being formalized with design partners.
Who is the founder, and why her?
Danya Dotan — a systems architect combining behavioral science, systems thinking, and AI product design. Her work focuses on execution recovery, operational continuity, and human–AI collaboration: the infrastructure organizations need to adopt AI through trust rather than surveillance. The thesis comes from directly studying where work breaks first.
What are you asking for?
Three things: 3–5 enterprise design partners, live pilot environments, and go-to-market & platform support.
What are the biggest risks?
Enterprise sales cycle length (mitigated by design-partner-led land-and-expand on a single broken workflow); integration breadth across heterogeneous stacks (mitigated by the read-and-route, no-rip-and-replace architecture and standard connectors); and the privacy narrative (mitigated — and turned into a moat — by anonymous-by-architecture design that makes trust a feature, not a caveat).
How do you measure success in a pilot?
Four outcome metrics: time to first action, recovery rate from stalled moments, reduction in dropped handoffs, and AI adoption inside approved workflows. The core engineering target is a recovery-loop latency of ≤30s from detection to a routed recovery action.