Learn how to use HeadOps

When you first sign in to HeadOps with your Google account, a Workspace is automatically provisioned for you. A workspace is your company's secure data boundary — all projects, teams, stage types, and holiday calendars are scoped to it.

Inviting Team Members

Navigate to Settings → Workspace to manage your team. Invite colleagues by entering their email address and selecting a role:

• Admin — Full access including workspace settings, member management, and danger zone operations.
• Editor — Can create and modify projects, components, stages, and allocations.
• Viewer — Read-only access to the timeline and team views.

HeadOps organizes your production data in a strict four-level hierarchy. Understanding this structure is essential for effective planning.

Projects

A Project represents a single client order or conveyor installation. Each project has an order number (displayed as the primary label on the timeline), a client name, and an official end date that serves as the deadline for delivery scheduling.

Components

A Component is a physical piece within a project — for example, a specific conveyor section identified by its client commission number and part type. Components appear as individual rows on the planning timeline. Each component can have its own deadline date, which overrides the project-level deadline for scheduling purposes.

Stages

A Stage is a manufacturing step required for a component — such as "Pre-weld", "Electrical Install", or "Testing". Each stage has a defined duration in working days, a configurable work week (5-day or 6-day), and can optionally observe public holidays. Stages are linked to Stage Types, which are reusable templates you define in Settings.

Allocations

An Allocation is the scheduled assignment of a team to complete a stage. It defines the team, start date, end date, and working duration. Allocations appear as colored blocks on the Gantt canvas, and can be dragged to trigger automatic rescheduling.

Defining Stage Types

In Settings → Stage Types, define the types of manufacturing stages your factory uses. Each stage type has a name, a default duration (in working days), and a color that will appear on the timeline. When adding stages to a component, you pick from these predefined types.

Linking Teams to Stage Types

Teams can be associated with one or more stage types, defining which kinds of work they're capable of performing. This many-to-many relationship powers the Auto-Allocation Wizard — when the system needs to assign a team to a stage, it only considers teams that are linked to the appropriate stage type.

Working Week Configuration

By default, all teams operate on a standard Monday-to-Friday (5-day) working week. However, individual stages can be set to a 6-day mode (Monday-to-Saturday) when certain teams need to work weekends for critical operations.

Public Holidays

Navigate to Settings → Public Holidays to manage your workspace's holiday calendar. Each holiday has a date and a label. When a stage has "observe holidays" enabled (the default), the scheduling engine will skip holiday dates when calculating end dates — effectively extending the calendar duration without consuming working days.

Holidays are workspace-scoped: different companies can maintain entirely different holiday calendars. New workspaces are seeded with default public holidays for your region.

Navigating the Canvas

The planning timeline is a full-featured Gantt canvas. The left side displays a two-column hierarchy of project order numbers and component names. The right side is the scrollable timeline with day columns, weekend shading, holiday markers, and a blue "today" indicator.

Adding Projects and Components

Click the "+ New Project" button in the top-left corner of the canvas to create a new project. Within a project row, click the "+" button to add components. Each component can then be expanded to reveal its stages — both scheduled and backlog.

Scheduling Stages

Backlog stages appear in the component's expanded panel. Drag a backlog stage onto the timeline to create an allocation. Once placed, you can click on any allocation block to open the Stage Popover, where you can adjust the start date, duration, team assignment, and per-stage working week settings.

Rescheduling

Drag any existing allocation block to a new date. HeadOps will automatically compute the cascade effect using the EDF rescheduling engine. If the move would cause new deadline violations, you'll see a warning modal with the option to force the schedule or cancel the operation.

Every schedule starts with a deceptively simple question: "If a task takes 5 working days and starts on Wednesday, when does it end?" The answer depends on your working week and whether any holidays fall in between.

HeadOps solves this with a day-by-day counter. Starting from a given date, it walks forward through the calendar, one day at a time, and only counts the days that qualify as "working days." It skips:

• Weekends — Saturdays and Sundays in 5-day mode, or just Sundays in 6-day mode.
• Public holidays — any date you've added to your workspace's holiday calendar.

When the counter has tallied up enough working days to match the stage duration, that calendar date becomes the end date. This is why a "5-day" stage that starts on a Thursday will end the following Wednesday — because Saturday and Sunday aren't counted.

Imagine you have three stages lined up back-to-back: Pre-weld → Weld → Paint. If you push Pre-weld forward by 3 days, you'd expect Weld and Paint to shift forward by 3 days too. That's exactly what HeadOps does — but smarter.

How It Works

When you drag an allocation block to a new date, HeadOps measures the working-day gap between the moved stage and every later stage in the same project. It doesn't count raw calendar days — it counts the actual working days between them, using each stage's own work week and holiday settings.

Then, starting from the new date you chose, it re-applies those same working-day gaps. This means if there was a 2-day buffer between Pre-weld and Weld before the move, there will still be a 2-day buffer after the move — even if weekends or holidays shift positions.

This is the "big brain" of HeadOps. When you move a component, the engine doesn't just cascade stages within that project — it checks whether your move has accidentally double-booked a team, and if so, it intelligently reshuffles the affected work across your entire factory. Here's how it thinks, broken down into five steps:

Phase 1: Lock Your Move

The engine starts by honoring your decision. It schedules all stages of the component you moved, starting from the new date you chose, and marks those teams as "busy" for those dates. Your move is treated as a non-negotiable anchor — everything else adjusts around it.

Phase 2: Find the Affected Work

Next, the engine scans every other component in the system and asks: "Does any of this component's stages use the same team, on overlapping dates, as the work I just locked in?" Only components that answer "yes" are flagged for rescheduling. Everything that doesn't conflict stays exactly where it is.

Phase 3: Sort by Urgency (Earliest Deadline First)

The flagged components are now arranged in a priority line. The component with theclosest delivery deadline goes first. If two components share the same deadline, the one that was originally scheduled earlier gets priority. If they're still tied, the longer job goes first (since it's harder to fit into remaining gaps).

Phase 4: Fill the Gaps

Now, for each component in the priority queue, the engine schedules its stages one by one. For each stage, it asks: "When is the assigned team next available?" It uses an efficient jump-ahead technique — instead of checking every single day, it skips over entire blocks of busy time. If Team Alpha is booked from March 3–7, the engine jumps straight to March 10 (the next working day after the 7th).

Each stage within a component is placed one after the other — a later stage can only start after the previous stage finishes. This preserves the natural manufacturing sequence (you can't paint something that hasn't been welded yet).

Phase 5: Check For Deadline Violations

Finally, the engine checks every component's last stage to see if it finishes after the delivery deadline. If so, it calculates exactly how many days overdue the project will be and reports this to you. It also tells you whether this violation is new(caused by your move) or pre-existing (it was already overdue before you dragged anything). This distinction helps you make informed decisions — a new violation is a warning, while a pre-existing one is just a reminder.

When you add a new component with multiple stages, you face a combinatorial puzzle: each stage can potentially be assigned to several different teams. The number of possible combinations multiplies quickly — 3 stages with 4 eligible teams each already creates 64 possible schedules. With 5 or 6 stages, you can easily reach tens of thousands.

The wizard tries them all. Here's the process:

Step 1: Find Eligible Teams

For each stage, HeadOps looks at the stage type (e.g., "Pre-weld") and finds all teams that are linked to that type. If Stage A is a "Weld" and Teams Alpha, Bravo, and Charlie can all weld — those three are the candidates for Stage A.

Step 2: Generate All Combinations

The engine creates every possible combination of team-to-stage assignments. If Stage A has 3 options, Stage B has 2 options, and Stage C has 4 options — it generates all 3 × 2 × 4 = 24 possible schedules. A built-in safety guard caps this at 100,000 combinations to keep things fast.

Step 3: Simulate Each Schedule

For every combination, the engine simulates the schedule as if you had manually placed each stage. It checks each team's existing calendar, finds the earliest available slot that doesn't conflict with their current workload, and records the resulting end date.

Step 4: Pick the Winner

The combination that produces the earliest overall finish date wins. If even the best combination exceeds the delivery deadline, the wizard tells you exactly how many days overdue it will be — so you can decide whether to proceed, extend the deadline, or add more teams.

A "conflict" in HeadOps means a single team has been assigned to two different stages whose date ranges overlap. Think of it like booking the same meeting room for two meetings at the same time — one of them has to move.

How Detection Works

The engine groups all allocations by team. For each team, it sorts its assignments by start date and then scans through the list looking for overlaps. Two blocks overlap when one starts before the other ends.

When an overlap is found, both allocation blocks are flagged as "conflicted." On the timeline canvas, these blocks are highlighted with a bright red overlay, making them impossible to miss. A conflict count badge also appears in the planning toolbar.

Resolving Conflicts

You have two options. You can manually drag one of the conflicting blocks to a new date — which triggers the cascade and dynamic rescheduling algorithms described above. Or you can click "Reschedule All", which triggers a global reschedule that rebuilds the entire factory schedule from scratch using the EDF priority order, guaranteeing zero conflicts in the result.