This is an advanced lesson. You can run Horizon successfully for months without touching time estimate policies — the baseline policy ships with sensible defaults, and most accounts only revisit this once NextAvailable assignment is firmly in place and the team wants to sharpen accuracy. Skip this until everything in the previous lessons is stable and producing real data you'd like to tune against.

Why this is the last knob to turn

Problem: NextAvailable assignment uses a duration estimate to ask "how long will this ticket take?" and pick the user with a fitting open window. If every ticket gets the same default duration — say 60 minutes — then a 5-minute password reset and a 4-hour project both look the same to the scheduler. Calendar fit decisions are coarser than they could be.

Horizon's answer: Time Estimate Policies. A policy assigns a duration estimate to a ticket based on its characteristics — "password reset → 15 min", "new user provisioning → 90 min", "backup investigation → 2 hours". NextAvailable pulls from the policy that applies to the team handling the ticket and gets a useful number instead of a flat default.

You don't need time estimate policies to run NextAvailable — every account ships with a baseline policy that returns a single default duration. You add tuned policies (and rules within them) when you want assignment decisions to reflect ticket-specific reality.

Where time estimate policies live

Open the admin panel and navigate to Components → Time Estimates. You'll find:

Every account has a baseline policy that ships with the system. It cannot be disabled or deleted — it's the ultimate fallback when a team has no specific policy assigned. You can edit its default duration and add rules to it.

How estimate resolution actually works

When NextAvailable (or anything else) asks "how long will this ticket take?", Horizon resolves the estimate in three layers:

1. Find the policy — start with the team's linked Time Estimate Policy. If the team has none, fall back to the account's baseline policy.
2. Match a rule within the policy — each policy has zero or more rules with conditions (e.g. "type = Password Reset", "priority = High and category = Backup"). The rule with the most specific matching conditions wins. Specificity is measured by the number of non-null conditions.
3. Fall back to the default — if no rule matches, use the policy's default_duration_minutes.

The resolution is fully deterministic: same ticket, same policy state, same answer.

Anatomy of a Time Estimate Policy

A policy has:

• Name — internal identifier (e.g. "Service Desk - Standard").
• Default duration (minutes) — the fallback when no rule matches. This is the one number you change first when you create a new policy.
• Active flag.
• Rules (relation manager) — duration overrides for matching tickets.
• Teams (relation manager) — teams that use this policy. A team can link to exactly one policy at a time.

A rule has:

• Name — internal label.
• Conditions — a match group of ticket criteria (type, priority, queue, custom fields, etc.). null conditions mean catch-all.
• Duration (minutes) — the duration to use when this rule matches.

When to add a custom policy

Don't create custom policies on day one. Use the baseline with a sensible default duration (e.g. 30 or 60 minutes). Watch how NextAvailable performs with that. Then, if you observe specific patterns where the wrong duration is causing bad assignments, add rules to the baseline — or create a team-specific policy if a particular team's work shape is fundamentally different from the rest of the org.

Common reasons accounts add custom policies:

• A team handles a class of work with very different durations from the org average (e.g. project services vs. service desk).
• A team's tickets follow different SLAs and the calendar layer should reflect that.
• Reporting needs duration accuracy at a granular level.

If the baseline policy plus a handful of well-targeted rules does the job, leave it at that. Layered policies are a maintenance cost.

Adding rules to a policy

1. Navigate to Components → Time Estimates and edit the policy you want to tune (start with the baseline if you're not sure).
2. Open the Rules relation manager.
3. Click Create.
4. Name the rule.
5. Build the conditions — use the match group editor to specify ticket criteria (type, priority, picklist values, etc.).
6. Set the duration in minutes.
7. Save.

When two rules could match a ticket, the one with more specific conditions wins. If you have a generic "type = Service Request → 30 min" and a more specific "type = Service Request and category = Onboarding → 90 min", the onboarding rule fires for onboarding tickets and the generic one fires for everything else.

Linking a team to a policy

By default, all teams use the baseline policy. To override:

1. Navigate to Components → Time Estimates and edit the policy you want a team to use.
2. Open the Teams relation manager.
3. Add the team(s).
4. Save.

A team can be linked to exactly one Time Estimate Policy at a time. If the policy is deleted, linked teams automatically re-link to the baseline (the baseline can't be deleted, so this fallback is always available).

Iterating on estimates

Time estimate tuning is observational. Watch for these signals:

• NextAvailable picks the wrong user consistently — the duration estimate may be off, causing wrong fit calculations.
• Calendars fill up too fast or too slow — durations are too high or too low globally; adjust the default.
• One ticket type chronically gets misassigned — that type probably needs its own rule.
• Time-on-ticket reporting shows large variance from estimates — re-baseline the rules for that bucket.

Don't chase precision. A duration estimate that's right within ±50% is plenty for NextAvailable to make better decisions than round-robin. Don't try to model a 17-minute ticket vs an 18-minute ticket.

When this is set up correctly (eventually)

• The baseline policy has a default duration that reflects your team's typical ticket.
• A handful of rules (often <10 per policy) override the default for distinct ticket shapes.
• Teams with fundamentally different work patterns have their own policies; everyone else uses baseline.
• NextAvailable decisions track real-world fit, not just rotation.

Tip: Treat this like SLA tuning, not initial setup. Ship with the baseline default. Let real ticket flow accumulate. Then, with a quarter of data behind you, look at where assignment is making bad calls and add rules surgically. Building out an elaborate estimate policy on day one is configuration theater — you don't have the data to know what the right numbers are yet.