Built-in task types vs custom: when to break out of the vocabulary

A task type is the most important field on a tracking event you will never think about twice. It carries the baseline: the number of minutes a human would have spent on the work the agent just did. Get it right and every execution converts cleanly into hours and money saved. Get it wrong and you multiply that error across every run, which at a steady 1,000 to 100,000 executions a month is how a dashboard ends up off by a factor of two.

HumanHours ships with a vocabulary of common task types so you do not have to invent names like ticket_routing, invoice_data_extraction or meeting_summary_30min from scratch. Each one carries a default baseline drawn from how long the work typically takes. The question every team hits during setup is the same: when do you trust the built-in, when do you override its number, and when do you abandon the vocabulary entirely and define your own type.

Leave it alone if the gap is under two minutes

The default baselines are calibrated to land most teams within a couple of minutes of reality. That margin matters, because the noise floor of your own reporting is already a couple of minutes wide. Sampling variance, partial automation, and adoption ramp all move the real per-task number around more than a small baseline mismatch does.

So the first rule is a non-action. If the built-in baseline is within two minutes of what your team actually spends on that task, leave it alone. Overriding it buys you precision that the surrounding noise immediately eats.

Override when the task is the same but your number is not

Override when the work is structurally the same as the built-in, but your time is genuinely different. The classic case is invoice_data_extraction. The built-in assumes a clean digital PDF. Your invoices arrive as scans, the line items need manual rekeying, and the real human time is 12 minutes, not 6. Same task, different reality. Set the override, and add a one-line note recording where the new number came from.

An override is workspace-scoped, so two teams in the same organization can run different baselines on the same task type without colliding. Finance reviewing the number later can see the calibration note instead of guessing.

Build a custom type when the work has no match

Create a custom task type when the work is structurally unlike anything in the vocabulary, not just slower or faster. A tenant intake triage that pulls from three channels, deduplicates against open cases, and opens a record in your system of record has nothing in common with a generic email_classification. Forcing it into a built-in name would attach a baseline that describes different work entirely.

The decision rule is one question: is this the same job at a different speed, or a different job? Same job, different speed means override. Different job means custom type. Anything that passes the first test does not need the second.

The cost of the wrong call is volume, not the single event

None of this matters at ten executions. It matters because tracking is a volume game. The same logic that makes HumanHours measure in human hours rather than API calls makes the baseline the lever that decides whether the final number survives a finance review. A two-minute error on a task that runs 40,000 times a month is 1,333 hours of phantom or missing savings, which is the difference between an agent that looks like it pays for itself and one that does not.

The vocabulary exists so teams stop reinventing the same names. Overrides exist for when your reality differs by minutes. Custom types exist for the work that does not fit. Most setups need all three, in that order of frequency.