adsoraBuild coverage around the work you can perform
Start with the property’s service ZIP and the requested trade. A branch may install replacement windows throughout a territory while sending bath work to a smaller area. Keep that distinction in the coverage table. A company-wide yes or no can accept a lead that no crew is assigned to serve.
Separate temporary capacity from permanent coverage. A branch that is full this week may still own the territory. Pausing that branch should not automatically make another branch responsible unless the business has approved the reassignment. Record the receiving queue and the person who owns the exception.
Use one table for approval and implementation
| Coverage column | Meaning |
|---|---|
| Service ZIP | Postal code as a string, preserving leading zeroes |
| Trade and project | Work accepted in this territory |
| Branch ID | Stable owner, even if the display name changes |
| Receiving queue | Where accepted records should appear |
| Status and dates | Active, paused or excluded, with effective times |
| Rule version | The approved list used for this decision |
Store the approved version with the implementation record. If a vendor challenges an out-of-area rejection, the team should be able to identify which territory rules were active when the lead arrived. Editing the current spreadsheet without keeping prior versions makes that reconstruction difficult.
Resolve overlaps before the system chooses
Two branches may both claim a ZIP. Decide whether one always owns the trade, whether capacity determines the assignment or whether a more precise address rule is needed. Do not let the incidental order of a spreadsheet decide who receives a billable inquiry.
Where ZIP-level coverage is too broad, define a second location check that the team can maintain. Ask which address fields are available at the buying stage and how uncertain addresses are handled. A routing rule should not pretend to have more location precision than the source actually supplied.
Choose an explicit outcome for unmatched records
An unmatched record can be rejected, held for review or sent to an approved central queue, depending on the program. Choose the outcome deliberately. A catch-all branch can hide missing coverage rules while creating work for a team that cannot serve the property.
Report unmatched and reassigned records separately. If the same project repeatedly needs manual rerouting, update the rule after the branch owner approves it. Keep the original assignment in the record so you can explain contact delays and avoid crediting a later branch with work it never received.
Test boundary cases whenever the territory changes
Use synthetic records for an included ZIP, an excluded ZIP, an overlap, an unknown value and a branch that is temporarily paused. Include a leading-zero ZIP to catch accidental number conversion. For each test, confirm the acceptance result and the destination queue.
Schedule changes with the source and the CRM owner using one effective timestamp. A receiving platform that accepts the new territory while the CRM still uses the old list can send the same lead to the wrong team. Review the first live assignments after the change and keep the old version available for reconciliation.