Module Status Board
11 modules
Grow
CRM
Phase 1Assessment Complete
Replaces HubSpot
1,447 deals, $598M pipeline, 145 workflows, 536 reports
Client Portal
Future — Unplanned
New capability
Client-facing project visibility and collaboration
Deliver
PSA / ERP
Phase 2Assessment Complete
Replaces Mavenlink (Kantata)
324 users, 296 projects, 260K time entries, $15.5M AR
Estimator
PlannedNot Assessed
Replaces Blueprint (Google Sheets)
Custom estimation tool with SOW generation
Strategic Planning / EOS
Phase 1In Progress
Replaces 90.io
18 teams, 216 users, 454 measurables, 165+ meetings
Operate
HRIS
Future — Unplanned
Replaces BambooHR
People records duplicated across 3+ systems
ATS
Future — Unplanned
Replaces Workable
Applicant tracking and hiring workflows
Finance
Future — Unplanned
Integration with NetSuite
Critical integration: invoicing and revenue recognition
Collaboration / Wiki
Future — Unplanned
Replaces Confluence
Knowledge base, policies, and procedures
Workflows / ITSM
Future — Unplanned
Replaces Jira
10+ business process workflows (SOW approvals, etc.)
LMS
Future — Unplanned
Replaces Lattice
Training, courses, and personalized learning paths
Assessment Tracker
| System | PRD | Usage Audit | Transcript Insights | Eval | Status |
|---|
| Current Scope |
| 90.io | ✓ | ✓ | ✓ | ✓ | Complete |
| HubSpot | ✓ | ✓ | ✓ | — | In Progress |
| Blueprint | ✓ | N/A (spreadsheet) | ✓ | — | In Progress |
| Mavenlink | ✓ | ✓ | ✓ | — | In Progress |
| Future — Not in current scope |
| BambooHR | — | — | — | — | |
| Jira | — | — | — | — | |
| NetSuite | — | — | — | — | |
| Lattice | — | — | — | — | |
| Workable | — | — | — | — | |
| Confluence | — | — | — | — | |
| DEEL | — | — | — | — | |
Build Sequence
12-week plan
EOS + CRM + Estimator as the primary 12-week effort. PSA foundation as stretch goal. Tracks overlap — shared data model enables parallel work.
Assess & Plan
Source module assessments, architecture planning, data model design
In progress — 3 of 11 systems assessed. CEO feedback applied March 27.
Data Model Approval
Canonical data model review and sign-off with Zaelab leadership
Gate — must be approved before build begins
Weeks 1–4: Foundation + EOS
Person, Organization, Auth, MCP framework. Scorecard, Rocks (L1→L2→L3), To-Dos, Issues, V/TO, Meetings, Accountability Chart
Replaces 90.io. Foundation entities shared across all modules.
Weeks 3–8: CRM
Pipeline S1–S7, Contacts, Companies, Deal stages, basic reporting
June 2026 HubSpot deadline. Overlaps with EOS tail. Built on shared Person + Organization entities.
Weeks 6–10: Estimator
Scope templates, Rate cards, Resource planning, SOW generation, margin approvals
Replaces Blueprint. Bridges CRM to PSA. Sold-as margin born here. Overlaps with CRM tail.
Weeks 8–12: PSA Foundation (Stretch)
Time tracking, Project setup from won deals, basic invoicing, staff margin
Stretch goal — scope calibrated based on EOS/CRM/Estimator progress. Full Mavenlink replacement continues in Phase 2.
Future Phases
Full PSA (Mavenlink), HRIS (BambooHR), ATS (Workable), Wiki (Confluence), ITSM (Jira), LMS (Lattice), Client Portal, Finance (NetSuite)
Sequenced after 12-week core effort ships
Open Questions
4 items
HubSpot marketing migration — 246 email campaigns, 636 forms used for client campaigns (ServiceNow, Shopify, etc.). This is separate from the CRM replacement. Does it stay in HubSpot, move to a different tool, or eventually come into ZOS?
Forecasting model requirements — Currently done in "a million spreadsheets." What exactly is being forecasted (revenue, capacity, demand, cash flow)? What inputs? Needs definition before building into CRM or PSA.
145 HubSpot workflows — How many are still active? Which encode critical business logic vs. legacy automations? Must be mapped before CRM migration.
Actual SaaS cost per system — The ~$1.5M total is Evan's verbal estimate. Need verified invoices/contracts for a real cost baseline and ROI model.
Cost Baseline
Known Breakdown
HubSpotMarketing Pro + Sales Pro + Content Enterprise + Data Starter
Mavenlink (Kantata)Enterprise PSA, 50+ seats (est. $35K–$66K+/yr)
90.ioUnknown
BambooHRUnknown
JiraUnknown
NetSuiteUnknown
Lattice, Workable, Confluence, DEELUnknown
Source: Evan Klein verbal estimate (Mar 18, 2026) — "we're spending like a million and a half dollars a year on systems." Not verified against invoices or contracts. System-by-system cost breakdown needed for ROI analysis.
1. The Problem
Zaelab is a ~$40M technology services company. 300 people. 25+ countries. Two acquisitions in the last year. 9+ SaaS platforms. ~$1.5M/year in software spend. And their CEO still can't answer a basic question about where the business is at.
"We have what the world tells us is a best in class PSA. We have HubSpot, we have Bamboo, we have Jira. And I still can't get a goddamn piece of information to know where the business is at." — Evan Klein
- System-hopping: 300 people bouncing between tabs all day.
- Duplicate records: Same person in BambooHR, Mavenlink, HubSpot, 90.io, DEEL, and spreadsheets.
- Disconnected lifecycle: Deal closes in HubSpot, manually recreated in Mavenlink, invoiced to NetSuite, forecasted in spreadsheets. None of these steps talk to each other.
- No margin visibility: Can't track sold-as, staff, or delivered margin because the data spans four systems.
- Forecasting in spreadsheets: "You're using a million spreadsheets for forecasting, and it's the bane of our existence."
- AI strategy blocked: Zaelab rates AI disruption as WARNING at 6-12 months, CRITICAL at 12-24. Can't build AI on fragmented data.
2. The Thesis
ZOS is a purpose-built, AI-native operating system that replaces Zaelab's siloed SaaS stack with a single platform that owns the data.
"This needs to have persistence and be the actual data storage. I need to sunset these other systems from the world." — Evan Klein
- Own the data. ZOS is the persistence layer. When a system gets replaced, it gets turned off.
- Modular architecture. Grow / Deliver / Operate. Discrete modules, shared data model.
- AI embedded, not bolted on. "Let me build the platform that embeds AI so that we're all using AI, but it's done in a way where we're bringing it to the people."
- MCP from day one. "Everything should have an MCP around this. That should be a day one thesis."
- Build for actual usage. "When you get down to brass tacks — I don't believe it's as complicated as replacing every single widget in HubSpot."
3. What We're Building
ZOS replaces 11 systems with 4 core modules (first effort) plus cross-cutting platform capabilities. Current status and assessment progress are tracked in the Tracker tab.
The build sequence follows the business flow: CRM (where deals start) → Estimator (where scope is priced) → PSA (where work is delivered and invoiced). EOS runs in parallel as the operational cadence layer.
The Four Modules
- Strategic Planning (EOS) — Scorecards, Rocks, V/TO, L10 Meetings, Accountability Chart. Replaces 90.io.
- CRM — Accounts, Contacts, Pipeline (S1-S7), Deal Scoring, Contract Generation. Replaces HubSpot (deals pipeline only — marketing deferred).
- Estimator — Project estimation, roles/rates/geographies, scope templates, SOW generation, AI-first reviews. Replaces Blueprint. Bridges CRM to PSA. This is where "sold-as margin" is born.
- PSA/ERP — Project financials, staffing, time entry, demand planning, utilization, margin management, invoice milestones. Replaces Mavenlink. Feeds NetSuite.
Cross-Cutting Platform Capabilities
These are the foundation that makes every module work together. They are as important as the modules themselves.
- Workflow / Approvals Engine — Configurable approval chains across all modules
- Reports / Dashboards — Unified reporting across all data
- Analytics & AI Layer — Embedded intelligence, not a bolt-on
- Role-Based Access & Permissions — Per-module, per-entity access control
- MCP Server — Programmatic access to all platform data and operations
- API-First Architecture — Every operation available via API
- Audit Trail & Versioning — Full history of changes across all entities
- Security / PII / DR — Enterprise-grade security for a 300-person, multi-country org
Remaining systems (BambooHR, Jira, NetSuite, Lattice, Workable, Confluence, DEEL) are future phases, not currently scoped. They will be addressed after the core four modules ship.
4. The Three-Stage Margin Model
The single most valuable capability ZOS can produce — and the one that's impossible with the current stack. It requires connected data across CRM, Estimator, PSA, and Finance.
- Sold-as margin — At deal close. Based on estimated hours and rates from the Estimator (Blueprint today). Revenue = net fees after discount. Cost = sum of estimated role costs. This is the margin the business commits to.
- Staff margin — When real people are assigned to the project. Their actual cost rates may differ from the generic role rates used in estimation. This reveals whether the staffing plan protects or erodes the sold-as margin.
- Delivered margin — Actual hours worked, actual rates, actual costs from time entries. This is ground truth. The delta between sold-as, staff, and delivered margin tells the full story of project profitability.
Today, sold-as lives in Blueprint, staff lives in Mavenlink resource plans, and delivered lives in Mavenlink time entries — three systems, no connection. In ZOS, it's one calculation across the Project lifecycle. See the Data Model tab for the field-level mapping.
6. Key Design Principles
Each principle grounded in what Evan and the team said. Runpoint recommendations labeled separately.
From Evan (direct)
- Own the data. Sunset the systems. "This needs to have persistence and be the actual data storage. I need to sunset these other systems from the world."
- Build for actual usage. "I don't believe it's as complicated as replacing every single widget in HubSpot. We don't need to do that."
- Follow the business flow. "Everything is kind of downstream from [CRM]. There's a natural progression — let's track how the business flows."
- Compound value, not incremental. "I don't get a lot of value if I replace one or two of these. I only get real value if I eventually get to the place where I could move most of this off."
- Platform over discrete agents. "Rather than let 100 people go off and build their own AI thing — let me build the platform that embeds AI."
- MCP from day one. "Everything should have an MCP around this. That should be a day one thesis."
- 100% operations tool. "It's 100% a day-to-day operations tool." Not a demo, not for equity value.
- Prove it, then scale it. "Can we chunk this up and prove it out with 90, prove it out with CRM, and use that as the testing ground."
- Collaborative build. "We want to work hand in hand with you and be active contributors."
From Runpoint (our recommendations)
- Design the data model with the end state in mind. Even Phase 1 entities should anticipate Phase 2+ needs.
- Transparent about unknowns. We say what we know and flag what we don't.
- Data quality as a visible feature. Surface missing fields, stale records, and incomplete data. Foundation for trustworthy AI.
This is a living document. Updated as assessments complete, modules ship, and scope refines.
Data Model
How ZOS connects the data that runs the business. Six scenarios show how information flows through the platform — from deals to delivery to the Monday morning L10. Below the scenarios: the entity model, the three-stage margin calculation, and open questions for validation.
Updated March 27, 2026. CEO feedback applied. EOS Record decomposed into 5 entities. Employee Record (formerly HR Profile) with BambooHR fields. 12-week parallel timeline: EOS + CRM + Estimator.
How Your Data Flows Through ZOS
6 scenarios
Each scenario starts with a situation you'd recognize, shows what ZOS does at each step, and ends with what changes. If you can say "yes, that's how it happens" at each step, the model is right.
Deal to Delivery
A new ServiceNow implementation deal comes in.
Today: Sales creates a deal in HubSpot. It moves through S1-S6 manually. At S7-Won, someone Slacks delivery. An SA opens Blueprint (Google Sheets), retypes the deal ID, builds scope, picks resources from a dropdown. Someone else goes into Mavenlink and retypes the client name to create a project. At no point can anyone compare delivered margin to what was sold.
In ZOS:
- Deal enters pipeline. One Project record: client (Organization), channel partner (Organization), platform, service type, deal amount, owner (Person). Shows on the pipeline board and revenue forecast immediately.
- Deal closes → Estimate created. SA builds scope line items with hours by discipline. Rate card auto-prices each role by region. Sold-as margin calculated: $450K revenue, $210K cost, 53% margin.
- Staffing. Delivery lead assigns real people via the staffing board. Each assignment creates a Resource Allocation with actual cost rates. Staff margin recalculates: 48% (dropped 5 points because a NA resource costs more than the generic role rate).
- Delivery & time tracking. Team logs time daily. Delivered margin updates continuously. Midway: $220K billed, $125K cost, 43% delivered margin.
- Project closes. All three margins visible in one view: 53% sold-as, 48% staff, 43% delivered.
What you get: One entity tracks the full lifecycle. Three-stage margin calculated automatically. "How does our estimating accuracy compare to delivery?" becomes answerable across the entire portfolio.
Entities: Project, Organization, Person, Contact, Estimate, Scope Line Item, Resource Allocation, Rate Card, Time Entry, Task, Financial Transaction, Pipeline Stage
Monday Morning — The Weekly L10
It's 9:00 AM Monday. The Leadership Team runs their L10 meeting.
Today: Someone spends Sunday night pulling numbers from HubSpot, Mavenlink, and spreadsheets, then manually types them into 90.io measurables. If they're late or wrong, the scorecard has stale data. 90.io has no connection to anything — when a number is off-track, there's no way to drill into why.
In ZOS:
- Scorecard auto-populates. Pipeline value (S3+) pulled live from Project. Utilization calculated from Time Entry data. Delivered margin from Project records. AR outstanding from Financial Transactions. No manual entry.
- Rock review grounded in data. A rock like "Launch ServiceNow practice" links to actual ServiceNow Projects — 3 in pipeline ($1.2M), 2 active ($400K). Progress is a count, not a feeling.
- Issues link to root causes. "Project margins trending below 40%" — the team drills into which projects, and whether the problem is estimation, staffing, or delivery.
- Meeting record persists. Duration, rating, attendees, decisions, issues resolved, to-dos created — all captured.
What you get: No more Sunday night data entry. When a measurable is off-track, drill from the scorecard into the actual deals, projects, or people driving the number.
Entities: Measurable, Rock, Issue, Meeting, VTO, Person, Project, Time Entry, Financial Transaction, Organization
New Hire Onboarding
A backend engineer joins the Eastern Europe team.
Today: HR creates a record in BambooHR. Somebody creates a login in Mavenlink. Somebody adds them to 90.io. Their cost rate gets typed into Blueprint and maybe Mavenlink — and the two might not match. No single view of this person exists. "Bamboo has the people record. PSA has a people record. There's records all over the place."
In ZOS:
- Person record created. Maria Ivanova, type=Internal, role=Backend Engineer. Lightweight identity shared across all modules.
- Employee Record created (restricted). Linked 1:1 to Person. Contains salary, tax ID, address, employment type, DEEL status. Only HR sees this — it never leaks into CRM or client-facing views.
- Rate card applied. Role (Backend) + Region (EE) maps to bill rate ($145/hr) and cost rate ($18/hr) automatically.
- Skills assigned, org placement set. Skills become searchable for staffing. Manager linked. She appears on the staffing board immediately.
- First project assignment. Resource Allocation links Maria to the project with her actual rates. Staff margin recalculates — her $18/hr vs. generic $15/hr is a $2,400 impact across 800 hours. Visible before the assignment is confirmed.
What you get: One person, one record, everywhere. HR data isolated from client-facing data by design. Staffing decisions show cost impact before you commit.
Entities: Person, Employee Record, Organization, Geography, Skill, Rate Card, Resource Allocation, Project, Measurable, Rock
Margin Alert
A project's margin is slipping and nobody knows it.
Today: The Acme Corp project was sold at 50% margin. During delivery, an EE backend developer was replaced by a senior NA resource at 4x the cost rate. Delivered margin is now 31%. Nobody catches it until the quarterly P&L reconciliation. By then, $120K in margin has evaporated.
In ZOS:
- Staffing change happens. EE developer's allocation ends. NA senior assigned at $95/hr vs. original $18/hr.
- Staff margin recalculates instantly. Drops from 50% to 38%. Delta is 12 points.
- Threshold alert fires. Configurable rule creates an EOS Issue: "Acme Corp — staff margin dropped 12 points below sold-as (38% vs 50%)."
- Issue surfaces in Monday L10. Team IDS's it: find another EE resource, renegotiate the rate, or accept the hit. Decision and action items captured on the record.
What you get: Real-time margin monitoring instead of quarterly surprises. Instant diagnosis — sold-as: 50% (estimation fine), staff: 38% (staffing killed it), delivered: 31% (delivery ran over too).
Entities: Project, Resource Allocation, Person, Rate Card, Measurable, Issue, Time Entry
Quarterly Rock Review
Start of Q2. The leadership team reviews Q1 rocks and sets Q2 rocks.
Today: The team opens 90.io. Each rock owner says "on track" or "not on track." When a rock says "Launch ServiceNow practice," someone has to manually check HubSpot for pipeline, Mavenlink for projects, and a spreadsheet for revenue. The "on track" assessment is vibes.
In ZOS:
- "Launch ServiceNow practice" rock links to all Projects where platform=ServiceNow. ZOS shows: 3 deals in pipeline ($1.2M), 2 active ($400K), 1 delivered (47% margin).
- "Reduce margin variance to <5%" rock links to a Measurable tracking AVG(ABS(sold_as - delivered)) across completed projects. Current: 7.2%. Not on track — and you can see which projects are driving it.
- "Hire 5 EE backend engineers" rock links to Person records filtered by discipline + region + start date. Count: 3 of 5. Progress is a number.
- V/TO alignment. Every rock references which 1-Year Plan goal it supports. At the annual, see which goals had rocks that delivered and which didn't.
What you get: Rocks connected to real data. "On track" backed by pipeline, projects, people, and margins — not gut feel. The 90.io-to-everything-else gap is closed.
Entities: Rock, Measurable, VTO, Project, Person, Organization, Pipeline Stage
Channel Partner Reporting
Evan wants to see all activity for ServiceNow.
Today: Someone goes to HubSpot for deals, Mavenlink for projects, then stitches together pipeline, delivery, and revenue data in a spreadsheet. It takes a day. It's stale by the time it arrives. If Evan wants a different slice — "just Q4" or "ServiceNow vs. Shopify margins" — it's another day.
In ZOS:
- One click: ServiceNow portfolio view. Filter Projects by channel_partner=ServiceNow. Pipeline: 6 deals, $3.1M. Active: 4 projects, 44% margin. Completed: 8 projects, 41% margin. Total lifetime: $7.8M.
- Compare partners. ServiceNow 41% delivered margin. Shopify 47%. BigCommerce 38%. One query.
- Resource capacity by partner. Who has ServiceNow skills? Who's assigned? How much bench capacity exists? All answerable because Person + Resource Allocation + Project are connected.
- Partner rep relationships. ServiceNow Contacts with deal history per rep. "We did $1.2M through Sarah Chen last year. She's sent 4 new deals this quarter."
What you get: Partner reporting in minutes instead of days. Walk into a QBR with: 18 delivered projects, margin by engagement type, 6 in pipeline, 12 certified people ready to deploy. That's a different conversation.
Entities: Organization, Project, Contact, Person, Skill, Resource Allocation, Financial Transaction, Measurable, Rock
Entity Model
23 entities
Every entity below appeared in the scenarios above. Four layers: People & Org, Business Lifecycle, Operational, and Reference Data.
People & Organization
| Entity | What It Is | Scenarios | Status |
|---|
| Person | Lightweight core identity. Every module references this. Intentionally thin — detailed data lives in Employee Record or Contact.Fields
| name | text | |
| email | text | |
| type | enum | internal / external / candidate |
| auth_role | text | |
| manager_id | FK → Person | self-referential |
| status | enum | active / inactive / alumni |
| 1-6 | Draft |
| Employee Record | Restricted sensitive data for employees/contractors. Linked 1:1 to Person. Only HR sees this — never leaks into CRM views. Primary source: BambooHR. Employee documents (NDAs, contracts) are Files attached to this entity.Fields
| person_id | FK → Person | |
| employee_id | text | BambooHR employee ID |
| employment_type | enum | FTE / contractor / vendor |
| cost_rate | currency | hourly, from Rate Card |
| bill_rate | currency | hourly, from Rate Card |
| salary | currency | annual |
| salary_history | JSON[] | historical salary changes from BambooHR |
| title | text | |
| department_id | FK → Organization | |
| region_id | FK → Geography | |
| hire_date | date | drives tenure calculation |
| start_date | date | |
| address | text | restricted |
| emergency_contact | JSON | name, phone, relationship |
| tax_id | text | restricted (SSN etc.) |
| pto_balance | number | hours |
| deel_id | text | offshore payroll ref |
| bamboohr_id | text | BambooHR external ref |
| 3, 4 | Draft |
| Contact | External relationship data. Client contacts, partner reps, prospects. Enrichment target — auto-populates from LinkedIn, public data.Fields
| person_id | FK → Person | |
| organization_id | FK → Organization | |
| title_at_company | text | |
| phone | text | |
| role_in_deal | enum | decision maker / influencer / champion / end user |
| lifecycle_stage | enum | prospect / MQL / SQL / customer |
| linkedin_url | url | |
| enrichment_data | JSON | auto-populated external data |
| 1, 6 | Draft |
| Organization | Hierarchical. Clients, channel partners, departments, teams, practices. Tree structure with parent/child.Fields
| name | text | |
| type | enum | client / channel_partner / department / team / practice |
| parent_id | FK → Organization | tree hierarchy |
| leader_id | FK → Person | |
| accountabilities | text[] | EOS accountability bullets |
| industry | text | for clients |
| website | url | |
| enrichment_data | JSON | auto-populated for clients |
| 1-6 | Draft |
| Geography | 25+ countries across 3 rate regions (NA, EE, WE). Drives rate cards, payroll compliance, calendars.Fields
| region | enum | NA / EE / WE |
| country | text | |
| timezone | text | |
| currency | text | |
| holiday_calendar | JSON | |
| payroll_provider | enum | internal / DEEL |
| 3, 4 | Draft |
| Skill | Standalone lookup table for skills and certifications. Skills exist as both person attributes (via PersonSkill) AND project/estimate requirements. "This project requires ServiceNow skills" is a valid use case independent of who's assigned.Fields
| name | text | e.g. "ServiceNow", "React", "Project Management" |
| category | enum | certification / language / technical / methodology / other |
| description | text | |
| is_active | boolean | |
PersonSkill (junction)
| person_id | FK → Person | |
| skill_id | FK → Skill | |
| proficiency_level | number | 1-5 |
| certified_date | date | for certifications |
SkillRequirement (junction)
| entity_type | text | project / estimate |
| entity_id | FK | polymorphic ref |
| skill_id | FK → Skill | |
| required_count | number | how many people with this skill needed |
| min_proficiency | number | 1-5 |
| 1, 3, 6 | Draft |
Business Lifecycle
| Entity | What It Is | Scenarios | Status |
|---|
| Project | The hub. Deal → estimate → staffing → delivery → invoicing → close. Carries all three margins.Fields
| name | text | |
| client_id | FK → Organization | the end customer |
| channel_partner_id | FK → Organization | optional — not all projects have a channel partner (ServiceNow, Shopify, etc.) |
| deal_owner_id | FK → Person | |
| service_type | enum | Implementation / Advisory / etc. (7 values) |
| platform | enum | ServiceNow / Shopify / etc. (21 values) |
| billing_type | enum | T&M / Fixed Fee |
| stage_id | FK → Pipeline Stage | configurable S1-S7 |
| rate_card_version | FK → Rate Card | |
| deal_amount | currency | |
| sold_as_margin | pct | from Estimate |
| staff_margin | pct | from Resource Allocation |
| delivered_margin | pct | from Time Entries |
| start_date / end_date | date | |
| 1-6 | Draft |
| Estimate | Approach variant for a project. Up to 7 per project. The winning variant becomes the sold-as baseline.Fields
| project_id | FK → Project | |
| variant_name | text | Original, Short Timeline, etc. |
| discount_pct | pct | 0-100 |
| contract_type | enum | T&M / Fixed Fee |
| total_hours | number | calculated |
| gross_fees | currency | before discount |
| net_fees | currency | after discount |
| total_cost | currency | calculated |
| gross_margin_pct | pct | calculated |
| is_selected | boolean | the winning variant |
| 1 | Draft |
| Scope Line Item | A deliverable within an estimate. Hours by discipline. SOW-ready descriptions.Fields
| estimate_id | FK → Estimate | |
| sequence_id | number | display order |
| is_included | boolean | in/out of scope |
| category | text | Feature Set (epic) |
| name | text | Feature name |
| description | rich text | SOW-ready |
| assumptions | rich text | SOW-ready |
| hours_frontend | number | |
| hours_backend | number | |
| hours_integration | number | |
| hours_ux | number | |
| hours_additional | number | |
| 1 | Draft |
| Resource Allocation | Person assigned to project with rates and weekly hours. Where sold-as becomes staff margin.Fields
| project_id | FK → Project | |
| person_id | FK → Person | nullable for unnamed |
| role | text | |
| discipline | enum | 14 values |
| region | enum | NA / EE / WE |
| bill_rate | currency/hr | |
| cost_rate | currency/hr | |
| weekly_hours | JSON | array by week |
| total_hours | number | calculated |
| 1, 3, 4, 6 | Draft |
| Financial Transaction | Money in and out. Quotes, invoices, payments, revenue recognition. Fixed Fee projects: milestone invoicing is separate from rev rec (rev rec is by percent complete, not milestones).Fields
| project_id | FK → Project | |
| type | enum | quote / invoice / payment / credit_memo / recognition |
| amount | currency | |
| currency | text | multi-currency support |
| date | date | |
| due_date | date | |
| status | enum | draft / sent / paid / overdue |
| netsuite_id | text | external ref |
| line_items | JSON | |
| percent_complete | pct | for rev rec on Fixed Fee (not milestone-based) |
| recognition_method | enum | by_deliverables / by_hours / pm_judgment |
| recognized_amount | currency | revenue recognized to date |
| 1, 2, 6 | Not Started |
Operational
| Entity | What It Is | Scenarios | Status |
|---|
| Time Entry | Universal work record. 260K entries, 324 users. Highest-traffic entity.Fields
| person_id | FK → Person | |
| project_id | FK → Project | |
| task_id | FK → Task | |
| date | date | |
| hours | number | |
| billable | boolean | |
| notes | text | |
| approval_status | enum | pending / approved / rejected |
| approved_by | FK → Person | |
| locked | boolean | prevents edits after lock date |
| 1, 2, 3, 4 | Draft |
| Task | Work items across modules. Polymorphic: project tasks, EOS to-dos, rocks, workflow steps.Fields
| title | text | |
| description | rich text | |
| type | enum | project_task / eos_todo / eos_rock / workflow_step |
| assignee_id | FK → Person | |
| status | text | configurable per type |
| due_date | date | |
| parent_id | FK → Task | hierarchy (phases, sub-tasks) |
| project_id | FK → Project | |
| meeting_id | FK → Meeting | for meeting-generated tasks |
| is_recurring | boolean | |
| 1, 2, 5 | Draft |
| Measurable | Weekly/monthly/quarterly KPI tracked on the scorecard. 454 measurables across 18 teams. Phase 1 all manual entry; designed for future auto-calculation from CRM/PSA/Finance.Fields
| name | text | |
| owner_id | FK → Person | |
| team_id | FK → Organization | |
| goal | number | |
| unit_type | enum | currency / pct / number |
| period | enum | weekly / monthly / quarterly |
| operator | enum | gte / lte / eq |
| data_source | enum | manual / crm / psa / finance |
| values | JSON | time-series by period |
| 2, 5 | Draft |
| Rock | Quarterly goal with milestones and status tracking. Supports L1→L2→L3 hierarchy: L1 = company rocks, L2 = department, L3 = team. Allows tracing rock hierarchy across levels.Fields
| title | text | |
| owner_id | FK → Person | |
| team_id | FK → Organization | |
| quarter | text | e.g. Q2 2026 |
| status | enum | on_track / off_track / complete |
| milestones | JSON[] | simple milestones, human judgment for completion |
| linked_project_id | FK → Project | bridge to PSA |
| parent_rock_id | FK → Rock | self-ref for L1→L2→L3 hierarchy |
| 2, 5 | Draft |
| Issue | Short-term and long-term issues tracked through the Identify-Discuss-Solve process. 13 strategic issues actively tracked by Leadership Team.Fields
| title | text | |
| priority | number | IDS ranking |
| status | enum | open / resolved |
| ids_phase | enum | identify / discuss / solve |
| team_id | FK → Organization | |
| meeting_history | JSON[] | carry-forward context |
| 2, 4 | Draft |
| Meeting | L10, quarterly, and annual meetings with structured agendas. 165+ meetings for Leadership Team. AI-generated summaries.Fields
| type | enum | L10 / quarterly / annual |
| team_id | FK → Organization | |
| date | datetime | |
| duration | number | minutes |
| rating | number | 1-10 |
| attendees | FK[] → Person | |
| agenda_sections | JSON | L10 format |
| ai_summary | text | auto-generated |
| 2, 5 | Draft |
| VTO | Vision/Traction Organizer. Strategic planning document with core values, core focus, 10-year target, and annual plan. One per team/company level.Fields
| team_id | FK → Organization | |
| core_values | text[] | |
| core_focus | text | |
| ten_year_target | text | |
| one_year_plan | JSON | revenue, profit, goals |
| 2, 5 | Draft |
| Document | Generated artifacts: SOWs, proposals, contracts, change orders. Versioned.Fields
| project_id | FK → Project | |
| type | enum | sow / proposal / contract / change_order |
| template_id | text | |
| version | number | |
| status | enum | draft / sent / signed |
| file_id | FK → File | |
| generated_from | JSON | source entity refs |
| 1 | Not Started |
| Forecast | Revenue, capacity, demand, cash flow projections. Currently in spreadsheets.Fields
| type | enum | revenue / capacity / demand / cash_flow |
| period_start | date | |
| period_end | date | |
| value | number | |
| confidence | pct | |
| assumptions | text | |
| created_by | FK → Person | |
| 2 | Not Started |
| Approval Request | Workflow and approval tracking. Replaces 10+ Jira business workflows.Fields
| entity_type | text | project / estimate / sow / pto |
| entity_id | FK (polymorphic) | |
| chain_id | FK → ApprovalChain | |
| current_step | number | |
| status | enum | pending / approved / rejected / cancelled |
| requested_by | FK → Person | |
ApprovalChain
| name | text | e.g. "SOW Approval" |
| steps | JSON[] | approver_id or role, order |
| conditions | JSON | routing rules, e.g. "if margin < 65% route to CEO" |
MarginThreshold (reference)
| min_margin | pct | lower bound |
| max_margin | pct | upper bound |
| action | enum | auto_approve / require_approval |
| approver_role | text | COO / CEO |
| service_type | enum | optional — can vary by service type |
Default thresholds: >72.5% auto-approve, 65–72.5% COO approves, <65% CEO approves
ApprovalStep
| approver_id | FK → Person | |
| decision | enum | approved / rejected |
| decided_at | datetime | |
| notes | text | |
| 1 | Draft |
Platform Content (Horizontal)
These attach to any entity across the platform. Not owned by any single module.
| Entity | What It Is | Scenarios | Status |
|---|
| Note | Comments, observations, context. Attaches to any entity.Fields
| entity_type | text | polymorphic ref |
| entity_id | FK | polymorphic ref |
| author_id | FK → Person | |
| content | rich text | |
| is_internal | boolean | hidden from client portal |
| created_at | datetime | |
| All | Not Started |
| File | Documents, images, PDFs attached to any entity. Supports both direct uploads and external references (Google Docs, Google Sheets, etc.). Versioned. Employee documents (NDAs, contracts) are Files attached to Employee Record.Fields
| entity_type | text | polymorphic ref |
| entity_id | FK | polymorphic ref |
| filename | text | |
| reference_type | enum | upload / external_link |
| external_url | url | for Google Docs, Sheets, external references |
| mime_type | text | |
| size_bytes | number | |
| storage_url | url | for uploads |
| version | number | |
| uploaded_by | FK → Person | |
| 1, 3 | Not Started |
| Recording | Audio/video with derived transcripts. Meetings, deals, contacts.Fields
| entity_type | text | polymorphic ref |
| entity_id | FK | polymorphic ref |
| file_id | FK → File | |
| duration_seconds | number | |
| transcript | text | derived from audio |
| transcript_status | enum | pending / complete |
| participants | FK[] → Person | |
| 2 | Not Started |
| Activity | System-generated audit log on every entity. Automatic.Fields
| entity_type | text | polymorphic ref |
| entity_id | FK | polymorphic ref |
| action | enum | created / updated / deleted / assigned / approved |
| actor_id | FK → Person | |
| timestamp | datetime | |
| changes | JSON | field-level diff |
| All | Not Started |
Reference Data
| Entity | What It Is | Scenarios | Status |
|---|
| Rate Card | Versioned billing and cost rates. 52 entries per version. Old projects keep their original card.Fields
| version | text | e.g. "2025" |
| effective_date | date | |
| entries | JSON[] | region, discipline, role, cost_rate, bill_rate |
| 1, 3, 4 | Draft |
| Pipeline Stage | Admin-configurable deal stages. Editable without code changes.Fields
| name | text | e.g. "S3 Solution" |
| display_order | number | |
| is_closed | boolean | |
| is_won | boolean | |
| default_probability | pct | |
| color | text | hex |
| 1, 5, 6 | Draft |
Three-Stage Margin Model
The core value proposition. Today this data spans 4 systems with no linkage. In ZOS, it's one calculation on the Project entity.
| Stage | When | Revenue | Cost | Source Today |
|---|
| Sold-as Margin | Deal closes, estimate selected | Estimate.net_fees | Estimate.total_cost (generic role rates) | Blueprint |
| Staff Margin | Real people assigned | SUM(allocation.bill) - discount | SUM(allocation.cost) at actual person rates | Blueprint → Mavenlink |
| Delivered Margin | Work complete | SUM(time.hours * time.bill_rate) - discount | SUM(time.hours * time.cost_rate) | Mavenlink |
Answered Questions
14 resolved
Questions resolved across two feedback sessions with Evan Klein (March 26-27). Responses captured and applied to the data model.
Discounts are estimation-specific. Discounts apply at the estimate level only. Sold-as margin locks at deal close. No further discounts applied at staff or delivery stages (unless exceptional circumstances like a client mistake, which isn't a priority use case).
Change orders: separate estimate, separate margin. Each change order creates a new Estimate with its own sold-as margin. The Project shows aggregate margin across all estimates (original + change orders). Typically a separate sales opportunity in HubSpot.
Staffing trigger: 75% forecast confidence. When a deal reaches 75% confidence, it triggers the staffing team radar. Not a hard gate — a signal.
Channel partner: optional on projects. Not every project has a channel partner. channel_partner_id is nullable.
Measurables Phase 1: all manual entry. Design for future auto-calculation from CRM/PSA/Finance, but Phase 1 is 100% manual.
Rocks: simple milestones, human judgment. L1→L2→L3 hierarchy desired. Parent rock linkage via parent_rock_id.
Cost rates: currently average by role. Future: actual person-specific costs with visibility restrictions.
Fixed fee margin tracking. Track full bill rates even on Fixed Fee (what the estimate was built against). Track percent complete for revenue recognition — not the same as milestone invoicing. Percent complete can be measured by deliverables, hours, or PM judgment. Need flexibility — different project sizes may use different methods. Milestone invoicing and rev rec are separate concerns.
Margin thresholds: uniform, not by service type. Currently no variation by service type. This is a new policy just deployed. Jira workflow for deal approvals available for reference.
Multiple projects: yes, very common. No blocking constraint. Some people on 16 projects. AI opportunity to flag over-allocation but deferred to PSA phase.
DEEL: employer of record only. No impact on cost rate or how they're treated. DEEL contractors are just employees who happen to work in a country where Zaelab has no legal entity. Treat as normal employees.
Partner hierarchy: 5-7 levels deep. Org chart + sales territory mapping. Regional managers, sales teams, sales engineers covering multiple teams, partner go-to-market people per industry, product teams. Complex — think org chart plus territory map.
BambooHR access: confirmed. Access taken care of.
Jira workflows: confirmed complex. Complexity varies. Simple approval chains to conditional routing (e.g., contracts over $250K or below-target margin trigger different approver paths). More information available from Thomas and outside contractors.
Open Questions
4 remaining
Remaining open items after two feedback sessions.
Data & Migration
HubSpot data migration scope. Evan confirmed we need to bring in old deals. What's the cutoff? All historical deals or a date range? What fields are required vs. nice-to-have?
Historical Mavenlink project migration. Active projects: yes, migrate. Historical: TBD — Evan needs to circle back on value of bringing over past projects.
How is acquired company data handled? Two acquisitions in the last year. Separate system instances? Identity merge needed?
NetSuite integration architecture. Invoice schema, GL mapping, sync triggers, failure handling. Hard dependency for Financial Transaction design.
Technical Reference: System Mappings
Where each entity's data lives today across existing systems. Blank cells represent gaps — data that doesn't exist in that system.
| ZOS Entity / Field | 90.io | HubSpot | Blueprint | Mavenlink | BambooHR | Lattice | NetSuite |
|---|
| Person (core identity) |
| Name | user.name | contact.name | Resource (named) | user.full_name | employee.displayName | user.name | entity.name |
| Email | user.email | contact.email | — | user.email_address | employee.workEmail | user.email | — |
| Type | — | contact.lifecyclestage | — | user.account_membership | — | — | — |
| Role / Title | user.seat | — | Role (dropdown) | user.role | employee.jobTitle | — | — |
| Manager | — | — | — | — | employee.supervisorId | user.manager | — |
| Employee Record (restricted) — primary source: BambooHR |
| Status | user.status | — | — | user.account_membership | employee.status | user.status | — |
| Cost Rate | — | — | Values.Cost | user.cost_rate | — | — | — |
| Salary | — | — | — | — | employee.payRate | — | — |
| Address | — | — | — | — | employee.address | — | — |
| Tax ID / SSN | — | — | — | — | employee.ssn | — | — |
| Employment Type | — | — | — | — | employee.employeeType | — | — |
| Start/End Date | — | — | — | — | employee.hireDate | — | — |
| Employee ID | — | — | — | — | employee.id | — | — |
| Salary History | — | — | — | — | employee.compensation | — | — |
| Emergency Contact | — | — | — | — | employee.emergencyContact | — | — |
| Documents (NDA, contracts) | — | — | — | — | employee.files | — | — |
| Contact (external) |
| Title at Company | — | contact.jobtitle | — | — | — | — | — |
| Company | — | contact.company | — | — | — | — | — |
| Deal Associations | — | association.deal | — | — | — | — | — |
| Lifecycle Stage | — | contact.lifecyclestage | — | — | — | — | — |
| Organization (hierarchy) |
| Client | — | company (427) | Company | account | — | — | customer |
| Channel Partner | — | company (partner type) | — | — | — | — | — |
| Department | A-Chart nodes | — | — | organization (dept tree) | employee.department | — | department |
| Team | team (18 teams) | — | — | — | — | — | — |
| Project Lifecycle |
| Pipeline (configurable) | — | deal | — | — | — | — | — |
| Won | — | deal | Project ID | — | — | — | — |
| Estimation | — | — | Approach Variant | estimate | — | — | — |
| Scope | — | — | Scope Line Items | — | — | — | — |
| Resource Plan | — | — | Resource Allocation | workspace_resource | — | — | — |
| Delivery | — | — | — | workspace (296) | — | — | — |
| Invoicing | — | — | — | invoice (2,922) | — | — | transaction |
| Rate Card |
| Version | — | — | "2025 Rate Card" | rate_card_set | — | — | — |
| Role + Region key | — | — | Combined (lookup) | role | — | — | — |
| Cost / Bill rates | — | — | Values sheet | cost_rate / bill_rate | — | — | — |
| EOS |
| Measurable | measurable (454) | — | — | — | — | — | — |
| Rock | rock | — | — | — | — | — | — |
| Issue | issue | — | — | — | — | — | — |
| Meeting (L10) | meeting (165+) | — | — | — | — | — | — |
| V/TO | vto | — | — | — | — | — | — |
Prototype Status
The current prototype (in zos/) is a 90.io clone. It replicated 126 features with a 97% scorecard feature match. That demonstrated engineering feasibility, but it missed the point.
Evan didn't hire us to rebuild 90.io. He hired us because 90.io is a data-entry form that can't connect to anything, can't surface intelligence, and forces manual input for every metric. The prototype scores well on feature parity. It scores zero on connected data, AI intelligence, and MCP access — the things that actually matter.
The prototype is a reference for how 90.io works, not the starting point for the real build. We will likely start fresh. The real build needs to deliver connected data, AI intelligence, and MCP access from day one.
What We're Actually Building — EOS Module
7 components
The EOS module rebuilt around what Zaelab actually needs: auto-populated data from other ZOS modules, AI-generated intelligence, and MCP access for programmatic interaction. Each component replaces the equivalent 90.io feature with a fundamentally better approach. EOS is part of the broader 12-week build covering EOS + CRM + Estimator (see Build Timeline below).
Status reflects the new build plan. The prototype's 126-feature count does not carry over.
Scorecard
Not Started
Weekly KPI tracking grid with period tabs, color-coded goals, inline editing, and grouping. The heartbeat of the EOS cadence — 454 measurables updated weekly across 18 teams.
Key improvement over 90.io: Auto-populated measurables from CRM, PSA, and Finance modules. Anomaly detection flags off-track metrics automatically. Trend prediction projects where measurables are headed. Data source indicators show whether each value is live from a system or manually entered.
Meetings
Not Started
Structured L10 meeting format with configurable agenda sections (Segue, Data, Rock Review, To-Do List, IDS, Conclude). Scheduling, attendance tracking, and meeting ratings. 165+ meetings for Leadership Team alone.
Key improvement over 90.io: AI-generated meeting summaries after each L10. Pre-meeting briefings that surface off-track measurables, behind-schedule rocks, incomplete to-dos, and new issues. Carry-forward context so IDS discussions include history from prior meetings.
Rocks
Not Started
Quarterly goal tracking with milestones, status (On Track / Off Track / Complete), kanban planning board, and V/TO goal linkage. 5 Company Rocks at the leadership level, individual rocks per person.
Key improvement over 90.io: Predictive completion based on milestone velocity — flag at-risk rocks at week 4, not week 11. Dependency mapping across rocks. Outcome linkage that tracks whether completing a rock actually moved the underlying measurable. Rock-to-project bridge connecting quarterly goals to PSA delivery.
To-Dos
Not Started
Task list with title, due date, owner, completion toggle, and overdue indicators. Private and team to-dos. 17 active to-dos on Leadership Team with real operational items.
Key improvement over 90.io: Meeting-generated to-dos automatically linked to the L10 and IDS discussion that created them — context is never lost. Completion nudges via notifications as due dates approach. Recurring to-dos that auto-generate for repeating tasks.
Issues (IDS)
Not Started
Short-term and long-term issue lists with priority, owner, cross-team sharing, and archive. 13 strategic issues actively tracked by the Leadership Team through the Identify-Discuss-Solve process.
Key improvement over 90.io: AI-suggested issue categorization and clustering when multiple teams raise similar problems. Resolution tracking that records what was decided and what to-dos resulted. IDS phase tracking showing how many meetings an issue has been discussed in. Auto-generated issues when scorecard measurables go off track for 3+ consecutive weeks.
V/TO (Vision/Traction Organizer)
Not Started
Strategic planning document with Core Values, Core Focus, 10-Year Target, 3-Year Picture, 1-Year Plan, 90-Day Plan, and SWOT analysis. Fully populated for Zaelab with revenue, EBITDA, and gross margin targets.
Key improvement over 90.io: Strategic alignment scoring — V/TO goals show which rocks are attacking them and their real-time status. Connected metrics pull live pipeline and revenue data instead of static numbers reviewed quarterly. The V/TO becomes a navigation root, not a static document.
Accountability Chart
Not Started
Hierarchical org chart with role titles, person assignments, photos, and accountability bullet points. Expand/collapse navigation, search, and draft charts. 7+ departments from Visionary through all teams.
Key improvement over 90.io: Built on canonical Person and Organization entities — the Accountability Chart IS the org structure for the entire platform. Shared with future HRIS module so there is no duplication. Role-based scorecard views let you click a person and see their measurables, rocks, to-dos, and issues in one place.
What We're NOT Building
5 descoped
These 90.io features have zero or near-zero usage at Zaelab. They are descoped permanently — the effort goes into connected data and AI features instead.
Headlines
Descoped
0 headlines, 0 cascading messages. Not adopted — announcements happen in Slack.
Knowledge
Descoped
Default content only, no custom content. Confluence handles this. Separate ZOS Wiki module if ever needed.
OS Toolbox
Descoped
0% mastery across all 22 EOS tools. EOS learning content is not our business to replicate.
Assessments
Descoped
1 assessment attempted in Q1 2025, never repeated. One-time experiment that did not stick.
1-on-1 Reviews
Descoped
Set up but not actively used. Lattice and BambooHR handle performance management. Will be part of the HRIS module.
Foundation Requirements
5 prerequisites
Platform capabilities that must exist before the EOS module build starts. The EOS module references these foundations — building without them creates the same isolated data problem 90.io has.
Person Entity
Canonical identity record with lightweight base + Employee Record + Contact split. Scorecard owners, rock owners, to-do assignees, meeting attendees, issue owners — everything references a Person. Must be the single golden record, not an EOS-specific user table.
Not Started
Organization Entity
Hierarchical tree structure supporting departments, teams, and companies. Every EOS artifact belongs to a team (18 teams). The Accountability Chart requires parent/child org hierarchy. Must be canonical across all ZOS modules.
Not Started
Auth / Role-Based Permissions
64 licensed seats need role-based access scoped to EOS: who can edit the V/TO, create company rocks, or view another team's scorecard. Basic auth exists but needs per-module, per-entity permission scoping.
Not Started
MCP Server Framework
Evan's day-one requirement. Programmatic read/write access to all EOS data: scorecard values, rock status, meeting history, issue lists, V/TO content. Enables Slack bots, CLI tools, and agent workflows. Build alongside the web UI, not after.
Not Started
Notification System
Overdue to-do alerts, off-track measurable warnings, upcoming meeting reminders, issue assignments. Push to web, email, and MCP channels (Slack). Basic infrastructure exists but needs EOS-specific event triggers.
Not Started
12-Week Build Timeline
4 tracks / parallel
Aggressive but aligned timeline matching Evan's expectation: EOS + CRM + Estimator within 12 weeks, with PSA foundation as a stretch goal. Tracks overlap intentionally — the shared data model (Person, Organization, Project) enables parallel work. June HubSpot deadline drives the CRM track.
W1
W2
W3
W4
W5
W6
W7
W8
W9
W10
W11
W12
Foundation + EOS
WEEKS 1–4
PSA Foundation
WEEKS 8–12 (stretch)
Weeks 1–4: Foundation + EOS Core
Foundation + EOS Track
Canonical Person and Organization entities. Auth and role-based permissions. MCP server framework. Scorecard with 454 measurables. Rocks with L1→L2→L3 hierarchy. To-Dos. Issues with IDS tracking. V/TO. Meetings with L10 format. Accountability Chart built on canonical entities.
Exit: Full EOS workflow live. 90.io can be sunset. Foundation entities (Person, Organization) ready for CRM and Estimator.
Weeks 3–8: CRM
CRM Track — overlaps with EOS tail
Pipeline with S1–S7 stages. Contacts and Companies built on Person + Organization entities. Deal stages, deal scoring, and pipeline board. Basic reporting and dashboards. June HubSpot deadline drives this track.
Exit: Deals pipeline operational. HubSpot CRM replacement live for sales team. Pipeline data flows to EOS Scorecard measurables.
Weeks 6–10: Estimator
Estimator Track — overlaps with CRM tail
Scope templates with SOW-ready descriptions. Rate cards with region/discipline pricing. Resource planning with skill requirements. SOW generation. Sold-as margin calculation. Margin threshold approvals (>72.5% auto-approve, 65–72.5% COO, <65% CEO).
Exit: Blueprint replaced. Deal→Estimate→SOW flow operational. Sold-as margin visible on every project.
Weeks 8–12: PSA Foundation (Stretch Goal)
PSA Track — stretch goal, scope TBD
Time tracking setup. Project creation from won deals. Basic invoicing and milestone management. Staff margin calculation from real person assignments. Active Mavenlink project migration (historical TBD).
Exit: Time tracking operational for new projects. Staff margin visible. Full Mavenlink replacement continues into Phase 2.
ZOS Project Tracker · Zaelab Operating System · Prepared by Runpoint · March 27, 2026