An ops manager turning on ServiceTitan Dispatch Pro, Sera Systems' scheduling AI, or FieldEdge auto-routing on Monday morning makes one decision that determines whether the 12-18% dispatch yield lift lands by day 60 or never lands at all: what the system is optimizing for. The factory defaults across all three vendors in 2026 optimize for call-count completion — fill every truck, route every open call, finish the board by 6 p.m. That default is wrong for a $1,600-$2,400/day baseline residential service shop trying to hit the $2,800-$3,500/day top-quartile RPT target, and it is catastrophically wrong for a replacement-heavy shop where the gap between a $620 service ticket and a $14K replacement quote is the entire P&L. The right configuration optimizes for profit per truck — revenue per tech, not call count — and it does not happen by checking a default box. It happens by building the tech skill tag library, loading 12-18 months of revenue history into the engine, writing capacity rules that protect install crews and time windows, codifying the override criteria the dispatcher and ops manager will defend at Friday review, and running a documented 30-day calibration where the configuration tunes against real shop performance before the system goes board-leading. This lesson is the ops manager's configuration playbook for that 30-day window — every screen, every field, every rule that turns a generic dispatch AI into a shop-specific profit-per-truck engine, and the calibration cadence that proves it works before anyone bets the dispatch board on it.

Profit per Truck as the Configuration Target

The 2026 dispatch AI configuration conversation starts with one sentence the ops manager writes at the top of the configuration document: "The system optimizes for profit per truck — measured as gross margin contribution per tech per day — and it does not optimize for call-count completion." That sentence is the configuration anchor every subsequent decision flows from. Without it, every default setting in Dispatch Pro, Sera, or FieldEdge tilts the engine toward calls-routed-per-shift, which is the wrong target.

The math the ops manager defends to the owner: a 7-truck residential HVAC shop at $5M revenue with shop baseline RPT of $1,900/day and top-quartile target $3,000/day has a $1,100/day per-truck gap to close. Across 7 trucks × 250 working days that is $1.9M of annual revenue ceiling. At ~38% gross margin that is $720K of annual margin contribution sitting between the shop's current operations and the top-quartile target — entirely a function of which calls get routed to which techs, in what order, and what the system holds back versus fills. Dispatch yield is the lever; profit per truck is the target the lever moves. Configure for profit per truck and the dispatch yield lift compounds across both the per-call uplift and the daily reshuffling cadence; configure for call count and the dispatch yield lift caps at single digits.

Sera Systems' 2026 profit-aware scheduling encodes this target as the default — revenue per tech is the optimization function out of the box, and configuration becomes about tuning the variance bands and the hold thresholds for shop-specific patterns. Dispatch Pro requires the ops manager to flip from the call-count default through skill-tag weighting and capacity rules into a profit-aware operating mode; the configuration burden is heavier but the lever is the same. FieldEdge's profit-per-truck mode in 2026 sits in the advanced configuration menu and requires the ops manager to load revenue history and tag travel-time penalties against expected job revenue. Different vendor surfaces, same target.

Building the Tech Skill Tag Library

The skill tag library is the foundation. The system cannot route the right tech to the right call if it does not know which techs are fast on heat pumps, which can sell a replacement, which are still in apprentice mode on linesets, and which are the install-crew specialists pulled at a $3K-$5K opportunity cost. Out of the box, the skill tag library is empty or carries the vendor's generic tags (HVAC, Plumbing, Electrical). That granularity is useless. The configuration job is to build a shop-specific skill tag library that captures the actual decision the dispatcher makes when routing a call.

The recommended 2026 skill tag taxonomy carries four dimensions per tech: trade specialty (heat pump, gas furnace, ductless mini-split, boiler, geothermal for HVAC; drain, water heater, sewer line, repipe for plumbing; panel, service upgrade, EV charger, generator for electrical), close-rate band (premium close 35-50% MPR, mid close 25-35%, base close 15-25%, training 0-15%), install-crew role (lineset specialist, ductwork lead, controls integrator, electrical lead, install apprentice, or service-only), and revenue band (top-quartile $2,800-$3,500/day service or $5K+/day commercial replacement, baseline $1,600-$2,400/day, training under $1,200/day). Every tech gets four tags minimum; senior techs typically carry 7-12 tags across multiple trade specialties and install-crew roles.

The tag library is a Google Sheet or shared doc before it is a system entry — built collaboratively between the ops manager, the service manager, and the senior dispatcher in a single 90-minute working session looking at the last 12 months of ServiceTitan / Sera / Housecall Pro data. Each tech's actual close rate by call type, actual average ticket by call type, and actual install-crew assignments by season get reviewed and the tags get assigned. After the working session, the tags get loaded into the dispatch AI's tech profile screen. The system now sees what the dispatcher sees.

Re-Tagging Cadence

Skill tags drift. The rookie at month 6 is no longer at month 1 close rates. Marco who was a lineset specialist last winter may have moved into ductwork lead by spring. The configuration cadence is a quarterly skill-tag review: every quarter, the ops manager pulls the actual trailing-90-day data on close rate by call type and average ticket by call type for every tech, compares to the current tag assignments, and updates. Techs who hit a new close-rate band get promoted; techs who slipped get re-tagged downward; new install-crew specialties get added as the work mix shifts. Without quarterly re-tagging, the system's skill tag view drifts from operational reality and the dispatch decisions degrade quarter over quarter.

Loading the Revenue History

The dispatch AI's predicted-job-revenue variable from Lesson 1 of the L2 dispatcher manual works only if the engine has revenue history to predict against. The configuration job is to load 12-18 months of clean revenue history into the engine before the system goes board-leading. Less than 12 months means the engine cannot capture seasonal patterns (Apr-Jun heat-pump replacement, Sep-Nov furnace replacement, Dec-Feb emergency no-heat at premium ticket); 18 months captures a full cycle plus the prior year's reference for variance bands.

The revenue history load is more than a data dump. The ops manager goes ticket by ticket — or in larger shops, calls a cleaned export from ServiceTitan / Sera / Housecall Pro — and validates: every closed ticket has a call type assigned (no "Misc" or "Other" categories), every ticket has an originating CSR booking note, every ticket has a final revenue and gross margin, every install ticket has the assigned crew composition. The clean-up effort runs 8-20 hours of ops manager time at a 7-truck shop with a year of dirty data; the time pays back inside week one because the engine's predictions become accurate rather than directional.

The validation gates the ops manager enforces during load: call-type assignment accuracy (target 95%+), revenue completeness (no missing finals), margin computation (gross margin populated). Vendor reps sometimes push to load and "let the system figure it out" — wrong advice; the prediction layer treats missing values as zero and artificially deflates expected revenue on dirty-data calls. Clean before you load.

Capacity Rules That Protect Margin

Capacity rules are where the configuration converts profit-per-truck intent into operational discipline. The dispatch AI defaults to a flat-capacity model: every tech has an 8-hour day, every hour is interchangeable, capacity declines linearly as calls fill the day. That default is wrong for trades because hours are not interchangeable — install crew hours protect $3K-$5K of lineset margin, time-window-committed hours protect show-rate at 92%+, recall-return hours protect 78-85% recall resolution. The ops manager writes capacity rules that encode each of those protections.

Install-Crew Capacity Block

The first capacity rule blocks install-crew hours from service-call reassignment for the duration of the install. If Marco is assigned to the Marin Park install at 7:30 a.m. with two helpers, his capacity for service calls is zero from 7:30 a.m. until the install crew breaks for lunch at minimum, and ideally until the install is signed off. The rule lives in Dispatch Pro's "tech availability" screen as a manually entered capacity block, or in Sera's "install-stack lock" feature, or in FieldEdge's "crew-assigned-not-routable" toggle. The configuration step: enable the install-crew capacity block on every install ticket the moment it lands on the dispatch board, before the install starts.

The rule's enforcement: if the dispatch AI proposes pulling Marco off the install for a service call routing more efficiently, the proposal gets flagged as a capacity-rule violation and routed to the dispatcher for explicit approval. The proposal can be approved (if the install is delayed by supplier or weather and Marco is the redeployment decision from Lesson 2 of the L2 dispatcher manual), but it cannot be auto-executed. The capacity rule is the system's enforcement layer for the install-crew protection override.

Recall-Return Tech Priority

The second capacity rule encodes the recall-return protocol. Every ticket that the system identifies as a recall (same complaint, same address, same equipment, original install / repair within a 90-day window) gets a hard routing constraint: route to the originating tech. The configuration step: enable the recall flag on every original install / repair ticket so the system can identify recalls automatically, and enable the recall-return-tech rule in the dispatch AI's routing logic. ServiceTitan and Sera surface this natively in 2026; FieldEdge requires the ops manager to enable the recall-tagging workflow explicitly during configuration.

The math the rule protects: originating-tech recall resolution at 78-85% versus fresh-tech at 42-55%. At a 7-recall/month shop the configuration rule preserves ~$14K of annual avoidable double-callback cost — directly attributable to the configuration step the ops manager made on day one. The rule is non-negotiable; the override criteria in the L2 manual exist for the rare case the originating tech is unavailable, but the system default is recall returns to the originating tech without question.

Time-Window Hard Commitment

The third capacity rule converts time-window booking commitments into hard scheduling constraints rather than soft optimization preferences. When the CSR books a call for the 10 a.m.-noon window, the system treats that window as immovable rather than flex-able. Dispatch Pro, Sera, and FieldEdge all default to soft time-window respect — the engine may push 10 a.m. to 10:25 to fit a more efficient sequence — and the configuration step is to flip the default to hard commitment. The override criteria from the L2 manual (within 10 min, customer notified, saving 30+ min) live above the system's default behavior; the system's default is to honor the window.

Override Criteria Built Into Configuration

The override criteria document from L2 Ch3 Lesson 1 — the dispatcher's handwritten document captured by Friday of week one — gets translated during configuration into system rules where possible and dispatcher discipline where not. The ops manager's job is to identify which override categories can be encoded in the system's configuration screen and which require human discretion every time.

Encodable in configuration: install-crew capacity blocks (above), recall-return tech priority (above), time-window hard commitment (above), customer named-request override (Dispatch Pro 2026 supports a "customer-preferred-tech" field on the customer record that the routing engine respects within the 24-hour booking window). Four of the five permanent override categories from L2 become configuration rules; the dispatcher's discretion handles the remaining edge cases.

Not encodable: comp plan dynamics (PIP status, bonus tier curves) and unseen variables (weather, traffic, tech mood, supplier dynamics). These remain in the dispatcher's hands every day because they change too fast or carry sensitive context the system should not see. The configuration boundary the ops manager draws explicitly: "These four override categories are system rules; these two are dispatcher discretion; the override-criteria document maintains both lists for Friday review."

The configuration documentation that survives turnover: a one-page "Dispatch AI Configuration Summary" the ops manager keeps in the shop's operations folder. Sections: optimization target, skill tag library reference, capacity rules, override criteria, calibration metrics. The new ops manager reads it on day one and inherits the configuration discipline.

The 30-Day Calibration Protocol

The configuration goes live in shadow mode for 30 days before it goes board-leading. The calibration protocol is the discipline that separates shops capturing the 12-18% dispatch yield lift from shops who flipped the switch and watched the day-30 decline. Shadow mode means the dispatch AI runs every 10 minutes, generates the proposed routing decisions, and surfaces them to the dispatcher — but the dispatcher continues making the routing decision the old way (wall board + intuition) and the system's proposals are logged but not executed. The 30-day comparison data is what the ops manager uses to validate the configuration before transitioning to board-leading mode.

Week One: Baseline Capture

Week one runs the dispatch AI in pure observation mode. The dispatcher continues normal operations; the system observes and records its proposed decisions but does not surface them prominently. The ops manager captures the baseline metrics: actual dispatch yield per call (revenue per call routed), actual RPT by truck per day, actual MPR by tech, actual recall rate, actual show rate. These five metrics are the calibration foundation. Without a clean baseline, week-30 results cannot be validated.

Weeks Two and Three: Shadow Comparison

Weeks two and three run shadow comparison. The dispatch AI surfaces its proposed decisions in a sidebar that the dispatcher sees but does not have to execute. The dispatcher makes the call the normal way; the AI's proposal sits next to it; the dispatcher records (with a single click) whether the AI's proposal matched, would have been better, or would have been worse. The data accumulates: agreement rate, predicted-revenue accuracy, predicted-close-rate accuracy. The ops manager reviews the data daily at 5 p.m. and pulls the patterns: where the AI is wrong (these become configuration adjustments), where the AI is right (these become discipline opportunities for the dispatcher to start trusting), where the AI's data is dirty (these become revenue-history clean-up tasks).

Week Four: Board-Leading Transition

Week four flips the system to board-leading. The dispatch AI proposes the routing decisions and the dispatcher reviews-then-approves rather than building from scratch. The override discipline from L2 kicks in: 5-15% override rate, one-line documented reasons, Friday review cadence. The ops manager runs daily check-ins through week four to catch any configuration regressions before they compound.

Day 30: Validation

Day 30, the ops manager runs the formal validation: compare week-four metrics to week-one baseline. Success criteria: dispatch yield up 8-12% (full 12-18% lift typically lands by day 60, not day 30, because the model needs the additional override-learning weeks), override rate stabilizing in the 10-15% band on a declining trajectory, zero install-crew breaks attributable to the system, zero recall misroutes attributable to the system, MPR steady or rising, recall rate steady or declining. If success criteria hit, the configuration is locked and the system continues with weekly Friday reviews. If criteria miss, the ops manager identifies which configuration element failed (skill tags, revenue history, capacity rule, override criteria) and runs a targeted fix before extending the calibration window.

Vendor-Specific Configuration Traps

Each vendor's configuration screen has named pitfalls the ops manager should know before sitting down with the implementation rep. Dispatch Pro's pitfall is the default "auto-fill mode" which optimizes for call-count completion regardless of the skill-tag weights; explicitly set the optimization function to "profit-per-truck" in advanced settings rather than relying on skill-tag weights alone. Sera's pitfall is the "fast-fill" toggle which overrides the profit-aware default during peak demand and reverts to call-count optimization without prominent flagging; disable fast-fill or set a high threshold so it only triggers in genuine emergency capacity situations. FieldEdge's pitfall is the "geographic clustering" weight which dominates the routing decision unless explicitly throttled; set geographic clustering as a tiebreaker rather than a primary weight when profit-per-truck is the target. The ops manager walks into the vendor implementation call with the configuration document already written and five named questions: optimization function setting, fast-fill / auto-fill disable, clustering tiebreaker weight, install-crew capacity blocks, recall-return tech priority as a hard constraint. Five questions, 90 minutes of vendor time. The rep who cannot answer all five gets escalated to the vendor's solutions architect before calibration starts.

The Ops Manager as Configuration Owner

The dispatch AI configuration is not a vendor responsibility, an IT responsibility, or a one-time setup task. It is an ops manager workflow that lives across the configuration phase, the 30-day calibration, the weekly Friday reviews, and the quarterly skill-tag re-tagging cadence. Shops that treat configuration as vendor-owned see day-30 declines because the configuration drifts from operational reality without an owner. Shops where the ops manager owns the configuration document, the calibration data, and the quarterly review capture the lift and compound it over years.

The role evolves the ops manager from "person who pulls dispatch reports" to workflow-architect owning how the AI plus the dispatcher plus the techs operate as a profit-per-truck system rather than three loosely coupled functions. Comp typically shifts to include a configuration-quality bonus (override trajectory, recall rate, install-crew-break rate) on top of the traditional ops manager base.

By day 60 the configuration is humming, dispatch yield is up 12-18%, override rate has dropped toward 8-11%, and the ops manager shifts attention to the next workflows (re-dispatch loop in Lesson 2, dispatch yield scorecard in Lesson 3). The configuration discipline is a one-time investment producing compounding returns — quarterly the skill tags refresh, the revenue history extends, the override criteria refine. The ops manager who built the configuration in week one is the ops manager whose shop hits top-quartile RPT by year-end.

Key Takeaways

• Profit per truck is the configuration target, not call count. The 2026 dispatch AI defaults across Dispatch Pro, Sera, and FieldEdge tilt toward calls-routed-per-shift; the ops manager's first configuration decision is to flip the optimization function to revenue-per-tech (weight 1.0) and call-count (weight 0.0).
• The 7-truck $1,100/day RPT gap is $720K of annual margin contribution. Shop baseline $1,600-$2,400/day to top-quartile $2,800-$3,500/day; configuration captures the lever, dispatch yield moves the lever, profit per truck is the target metric.
• Build a four-dimension skill tag library: trade specialty, close-rate band, install-crew role, revenue band. Every tech gets 4-12 tags; the master sheet lives in Google Docs before it lives in the system; re-tag quarterly against trailing-90-day data.
• Load 12-18 months of clean revenue history before the system goes board-leading. Validation gates: 95%+ call-type accuracy, every ticket has final revenue, every ticket has gross margin, every install has crew composition. 8-20 hours of ops manager time at a 7-truck shop; pays back in week one.
• Four capacity rules encode profit-per-truck in the system: install-crew capacity block (hours blocked from service reassignment), recall-return tech priority (hard routing constraint), time-window hard commitment (default flipped from soft to hard), customer named-request (Dispatch Pro 2026 customer-preferred-tech field).
• Four override categories are encodable; two remain dispatcher discretion. Install crew, recall, time window, named request go into configuration. Comp plan dynamics and unseen variables stay in the dispatcher's hands. The ops manager documents both lists in a one-page configuration summary.
• The 30-day calibration runs in four phases: week one baseline capture, weeks 2-3 shadow comparison, week 4 board-leading transition, day 30 validation against success criteria. Dispatch yield up 8-12% at day 30 is the gate; full 12-18% lift typically lands by day 60.
• Vendor-specific configuration traps: Dispatch Pro auto-fill default, Sera fast-fill toggle, FieldEdge geographic clustering weight. Five named questions for the vendor implementation rep on the kickoff call; rep who can't answer all five gets escalated to solutions architect.
• The ops manager is the configuration owner across configuration, calibration, weekly review, and quarterly re-tagging. Shops that treat configuration as vendor-owned see day-30 declines; shops where the ops manager owns it compound the lift over years and hit top-quartile RPT by year-end.