Skip to main content

Installer Tier And Status Rules

This is the locked V1 installer tier and status contract for IED.

Use this as the source of truth for:

  • installer tier semantics
  • installer status semantics
  • whether tier is global or region-specific
  • how routing should interpret installer state
  • what belongs in routing behavior rather than installer classification

V1 Tier Model​

V1 uses a simple operational installer hierarchy:

  • preferred The normal first-choice installer for a region
  • backup A trusted secondary installer for a region when preferred routing is not appropriate

Explicit rule:

  • overflow is not an installer tier
  • overflow is routing behavior triggered by capacity, availability, or other operational rules

Tier Scope​

Installer tier is region-specific in V1.

Meaning:

  • the same installer may be preferred in one region
  • and backup in another region

Installer company identity remains global, but routing tier should be attached to the installer-region relationship rather than treated as a single installer-wide truth.

V1 Status Model​

V1 uses a simple operational installer status set:

  • active Routable under normal rules
  • paused Temporarily unavailable for normal routing
  • inactive Fully not routable and effectively out of service

Do not introduce a more complex installer status system in V1 unless real operations demand it.

Status Semantics​

active​

The installer can receive assignments where region and tier rules allow it.

paused​

The installer is temporarily removed from normal routing until manually reactivated.

This is operational, not informational.

inactive​

The installer should not receive leads at all.

Inactive means fully not routable.

Routing Interpretation​

Recommended routing interpretation:

  • only active installers are normally routable
  • paused installers are temporarily excluded from normal routing
  • inactive installers are fully excluded from routing
  • overflow selection comes from routing logic, not a dedicated tier value

Contract Boundaries​

These do not belong inside the installer tier/status contract:

  • routing overflow logic belongs in routing rules, not installer tier
  • lead assignment state belongs in the lead assignment / routing contract
  • close-rate or quality scoring formulas belong in analytics or performance logic, not the core tier/status contract

Installer Data Needed For Later Work​

Installer-side data should support:

  • company identity
  • operational contacts
  • supported regions and postcodes
  • services offered
  • tier by region
  • status
  • capacity and availability notes
  • internal quality notes

Validation Scenarios​

The model should support these scenarios:

  • one installer can be preferred in one region and backup in another
  • an active preferred installer is routable in its region
  • an active backup installer is available when preferred routing is not used
  • a paused installer is excluded from normal routing until reactivated
  • an inactive installer is never routable
  • overflow handling can occur without introducing an overflow installer tier
  • admin filters can separate installers by status and by regional tier
  • installer status remains distinct from lead assignment state and routing outcomes