Automate inspector travel fees with service area conditions in pricing rules

Objective

• Automate inspector-specific travel and trip fees so pricing reflects who is assigned and which service area the job falls in—not only the job’s map location.
• Expose service area as a reusable condition anywhere Attik already configures structured rules (starting with pricing modifiers), so teams can combine inspector + service area logic without one-off workarounds.
• Unblock online scheduling and reduce manual payroll adjustments by auto-calculating travel fees for most bookings, with manual edits reserved for exceptions.

Background

• NE Region (2026-06-11): Operations and product discussed automating travel pricing enough that staff do not need to intervene on most orders. A practical path is conditional modifiers keyed on inspector plus service area, so specific inspectors can trigger different price and admin-fee changes in specific areas.
• The same discussion clarified that service area should not live only in service-area settings—it should appear in condition builders wherever rules are configured (e.g. “if service area is X” combined with inspector logic).
• Business pressure: Online scheduling is blocked until travel and trip-fee behavior is reliable enough to run without constant manual correction. The target discussed was ~90–95% of scenarios auto-calculated, with one-off exceptions handled manually.
• Current system behavior (not a bug): Expanded fees are one amount per service area polygon (expanded + expandedFee on the area). Pricing at schedule and edit time uses service-area/find-containing and applies the highest expandedFee among matching expanded areas via serviceAreaCost / expandedAreaPrice. Selected inspector does not change that fee today.
• Partial building blocks today: Conditional modifiers already support inspector-id in modifierPriceCalc.ts / modifierPriceAdjFn.ts, and scheduling passes inspectorIds when an inspector is assigned. Service area is not a condition attribute in templatingData.ts or modifier condition UIs yet.
• Related work (different axis): ATT-848 covers which services receive an expanded-area fee, not inspector-specific rules. ATT-1041 covers drive-time tiers and native inspector travel-fee configuration not addressed here.

Product Decisions

Locked

1. Delivery path — Near-term delivery uses service area as a condition input plus inspector×area rules in pricing modifiers (and equivalent evaluation paths), not a new native travel-fees schema in this issue.
2. Condition surfaces — Service area must be available anywhere structured conditions are configured that need it for pricing rules, not buried only under Settings → Service areas.
3. Success target — Aim for ~90–95% of travel-fee scenarios to auto-calculate in scheduling and online booking; manual adjustment is acceptable for exceptions only.
4. Online scheduler — Travel-fee automation must work in the online scheduler flow, not only internal scheduling tools.

Open

1. Expanded fee vs modifier travel — How today’s location-only expandedFee / serviceAreaCost path coexists with modifier-based travel rules (avoid double-charging; decide whether polygon expanded fees are superseded, zeroed, or kept for fallback).
2. Pre-slot online pricing — Whether online scheduler shows an area-only estimate before slot selection, then refines when inspectorIds are known, or requires another UX pattern.
3. Condition surface rollout — Whether v1 is modifiers only or also other condition builders (flows, quotes, etc.) in the same release.
4. Admin fee / payroll — How modifier-driven travel admin fees align with payroll and commission splits so configured rules do not fight existing admin modifiers.
5. Per-service expanded fees — Interaction with ATT-848 when multiple services on one job can carry area-related charges.

Scope

Backend

• Modifier evaluation: attik-backend/src/util/functions/schedule/modifierPriceCalc.ts — getAttributeValue supports inspector-id today; service area would need to be resolvable at quote/schedule time alongside existing ModifierContextData (inspectorIds, property, required info, equipment).
• Modifier model: attik-backend/src/models/modifierSchema.ts — conditional modifier shape already stores condition groups; no service-area attribute in evaluation yet.
• Service areas: attik-backend/src/models/serviceAreaSchema.ts, attik-backend/src/routes/serviceArea.ts — find-containing returns areas for a property; pricing flows must pass which containing area(s) apply into modifier context, not only a single expandedFee amount.
• Payroll context: attik-backend/src/util/functions/payroll/payrollContext.ts — applies modifiers with inspectorIds from inspections; travel rules must stay consistent here when admin fees change.
• Job payloads: attik-backend/src/util/functions/spectora/spectoraJobRequest.ts — serviceAreaCost on service matches; alignment needed if travel moves from polygon fee to modifier-driven amounts.

Frontend

• Condition catalog: attik-frontend/src/components/conditions/templatingData.ts — add service-area conditional keys; today modifierSpecificConditionalKeys includes inspector-id under the inspector group but no service-area group.
• Condition UI: attik-frontend/src/components/conditions/ValueConditionInput.tsx, Conditions.tsx — value pickers for new service-area attribute(s).
• Modifier settings: attik-frontend/src/app/tools/settings/services/[id]/Modifier/ConditionalModifier.tsx, ModifierConditions.tsx — conditional modifier builder; extend available groups/keys for service area.
• Price calculation: attik-frontend/src/util/functions/schedulingHelpers/calculateServicePrices.ts, usePriceCalculation.ts — today adds serviceAreaCost to primary service only; must reconcile with modifier-based travel once rules exist.
• Internal scheduling: attik-frontend/src/components/scheduling/NewSchedulingForm.tsx — passes serviceAreaCost: finalServiceArea?.serviceArea?.expandedFee and inspectorIds from scheduledInspector; recalc when inspector or area context changes.
• Online scheduler: attik-frontend/src/app/scheduler/SchedulerContext.tsx — passes expandedFee and inspectorIds from selectedSlotInspectorInfo after slot pick; travel automation must behave correctly in this path.
• Edit charges: attik-frontend/src/app/tools/inspections/[id]/components/EditChargesModal.tsx — location-based expanded fee today; must stay consistent when inspector changes on an existing job.

Out of scope (unless product expands)

• Drive-time tier fees (60–90 min, 90+ min) — tracked on ATT-1041.
• Native per-inspector fee overrides on inspector profile — tracked on ATT-1041; this issue may satisfy pricing behavior first via modifiers.
• Which services get an expanded-area fee — tracked on ATT-848.
• Mobile-specific UI unless mobile scheduling must surface the same calculated fees.

References

• Featurebase: inspector-specific travel fees by service area
• Featurebase: service area assignment expanded fee per inspector
• ATT-1041 — drive-time and native travel-fee configuration
• ATT-848 — expanded fee on which services
• attik-backend/src/util/functions/schedule/modifierPriceCalc.ts
• attik-frontend/src/components/conditions/templatingData.ts
• attik-frontend/src/app/tools/settings/services/[id]/Modifier/ConditionalModifier.tsx
• attik-frontend/src/util/functions/schedulingHelpers/calculateServicePrices.ts
• attik-frontend/src/app/scheduler/SchedulerContext.tsx