Carrier Programs: eligibility, required certs, and vendor approvals

What the Carrier Programs tab shows

A "carrier program" is a named preferred-vendor or network arrangement a carrier runs, the kind of thing you enroll in by name: Liberty Preferred, a Travelers ASP tier, and similar. Getting in, and staying in, usually comes down to three separate questions: are you enrolled, does your team hold the certifications the program requires, and is your documented process aligned with what the program expects. Historically those three lived in different places. The Carrier Programs tab puts them on one card, next to the relationships they actually govern, because your standing with Liberty Preferred is a client-relationship decision, not a credential-filing task.

Verinode does not enroll you in a program or file your certifications. It reads what your team has on file, reads the program's published requirements, and shows you exactly where you stand against each one. You decide whether to close a gap, and how.

Where to find it

Open Clients from the sidebar at /clients. The card slider across the top has nine tabs: Findings, Book of Business, All Clients, Health, Pushback, Scorecards, Carrier Programs, TPA Programs, Benchmarks. Carrier Programs sits between Scorecards and TPA Programs, tagged with a steel-blue accent.

At the top of the tab, an italic line frames the tab's job: "Your relationship with each carrier program, enrollment status + how close your team is to meeting the required cert profile. Program eligibility is a carrier decision; your credential state is visible on /certifications."

Empty state

If the underlying catalog has no program requirements loaded at all, the tab shows nothing but a centered line: "No program requirements in the catalog yet. Check back as research coverage expands." This is a catalog-coverage gap, not something in your data, Verinode's research pipeline hasn't published requirement data for any program yet in your market.

Once at least one program has published requirements, every program in the catalog shows as its own row on the tab, whether or not you're enrolled in it. Enrollment status is a separate flag layered on top (see below), so you can see what you'd need to qualify for a program before you ever apply to it.

Reading a program row

Each row is one carrier program, listed by name (for example, "Liberty Preferred"). Four things stack inside each row.

1. Required-cert coverage

Directly under the program name, a line reads X/Y required certs held · Z%, for example "3/5 required certs held · 60%". This counts against the program's published list of required certification slugs:

• X is how many of the program's required certifications your team or firm currently holds, counting anything with status active or expiring_soon (an expiring cert still counts as held until it lapses).
• Y is the total number of required certifications the program publishes.
• Z% is the coverage percentage. A program with zero published required certifications shows 100% by definition, there's nothing to be short of.

If any required certifications are missing, a Missing: line lists them by their slug in uppercase (for example "IICRC WRT, XACTIMATE LEVEL 2"). That's the punch list for closing the eligibility gap.

2. Enrollment status

If you have an enrollment record with the carrier for that program, a status label appears in the top-right of the row, "active" is shown in green; any other status (for example a lapsed or pending enrollment) is shown in muted gray. No label at all means Verinode has no enrollment record on file for that program, whether because you've never applied or because the record hasn't flowed in yet.

3. Process readiness

Below the cert-coverage line, a Process readiness sub-section appears for any program that has SOP expectations published in the catalog (a program with no SOP requirements shows nothing here). It compares the standard operating procedures you've documented in Verinode against what the program typically expects for that category of work, and reports one of three stances:

• ALIGNED (green): every required SOP category is documented at or above the program's target score. The summary reads "N/N required SOPs aligned."
• BELOW STANDARD (yellow): every required category has a documented SOP, but at least one scores below the program's target. The summary reads "N aligned · M below program target."
• UNDOCUMENTED (red): at least one required SOP category has nothing documented at all. The summary reads "M required SOPs undocumented · N aligned." Undocumented gaps take priority over below-standard ones in how the stance is set, because a missing SOP is a harder gap to explain to a carrier than a weak one.

Underneath the summary, up to three specific gaps are listed, each showing the SOP category and framework (for example "WATER MITIGATION · IICRC S500"), and either:

• "no SOP" in red, when nothing is documented for that category, or
• "LEAN [your score] < target [program's target]" in yellow, when you have a documented SOP but it scores below what the program expects. A dash appears in place of your score if the SOP exists but hasn't been scored yet.

Where the catalog has a citation for the requirement, it appears in italics beside the gap. If there are more than three gaps, a line reads "+ N more, see /processes Findings", pointing you to the full list on the Processes section.

4. Program vendor approvals

If the program has published vendor approval data, a Vendor Approvals block appears below process readiness, grouped into up to four rows by approval level, each shown as a pill with a count and the vendor names beside it:

• Required (copper): vendors the program mandates you use for certain scopes.
• Blocked (ember red): vendors the program prohibits.
• Preferred (copper): vendors the program favors but doesn't mandate.
• Approved (green): vendors cleared for use under the program.

Only levels with at least one vendor show a row; a program with no catalogued approvals shows no Vendor Approvals block at all. This is the same approval data that appears on a vendor's own profile (any program that has classified a vendor shows up there too), read here from the program's side instead of the vendor's.

Reporting a vendor approval

Underneath every program row sits a link: "+ Report a vendor approval." This is how you contribute a (program, vendor) approval level you know about that Verinode's research hasn't caught yet, a mitigation vendor your rep confirmed is required, a moisture-testing service the program just blocked, and so on. The link is hidden entirely if Verinode has no vendor catalog loaded for you to choose from.

1. 1Click + Report a vendor approval under the program you want to report on. The link expands into a small inline form, no page navigation.
2. 2Choose vendor. A dropdown lists every vendor in your catalog, each option showing the vendor's name and its category (for example "AquaDry Restoration · Water Mitigation").
3. 3Pick an approval level. Four options: Required, Preferred, Approved, or Blocked. Required is the default selection.
4. 4Notes (optional). Free text for context, for example why the vendor is blocked or what scope the requirement covers.
5. 5Source URL (optional). A link to the program document that states the approval, if you have one. This gives the entry a verifiable paper trail.
6. 6Click Save approval. While saving, the button reads "Saving…" and the vendor dropdown must have a selection or the form blocks submission with "Pick a vendor."

On save, the form resets and collapses, and the new approval appears in the Vendor Approvals block above within the same load, no page reload needed. If the vendor is already classified for that program, submitting again overwrites the existing entry rather than creating a duplicate, so a corrected approval level or an updated source link replaces the old one cleanly.

Submitted approvals are tagged internally as operator-reported, distinct from approvals sourced from a carrier document or from Verinode's own research. That distinction exists so future readers of the data (including you, on a later visit) can tell a confirmed carrier-document approval apart from a peer-reported one, both are shown the same way on this tab today, but the provenance is preserved underneath.

How this connects to the rest of Clients

The Carrier Programs tab reads the same client and vendor data as the rest of the section, but from the eligibility angle:

• A carrier's day-to-day relationship health (days to pay, collection rate, denial patterns) lives on the Health and Pushback tabs, not here.
• The required-SOP gaps this tab surfaces also emit as findings under the Processes section, so a documentation gap you see here can also show up as an actionable item elsewhere.
• Your actual certification records, expiration dates, and renewal reminders live at /certifications. This tab only reads coverage against them, it doesn't let you file or renew a certification directly.
• Vendor approval data submitted here also appears on the corresponding vendor's own profile page, and feeds the approval chips shown on Benchmarks Ratings rows and the Vendors list.

Best-practice example

Say Liberty Preferred shows "3/5 required certs held · 60%", with IICRC WRT and Xactimate Level 2 listed as missing. Process readiness reads UNDOCUMENTED, with a water-mitigation SOP flagged "no SOP." The Vendor Approvals block shows one vendor Blocked. Before you spend time chasing the missing certifications, the honest read is that you have three separate gaps stacked on one program: a credential gap, a documentation gap, and a vendor-conflict risk if you've been sending work to the blocked vendor without realizing it. Close the documentation gap first, it's usually the fastest to fix since it's within your control, then schedule the missing certifications, and confirm your current vendor roster against the blocked list before your next Liberty job.

Related reading

• Clients and carriers
• Forwarding documents
• Connecting your data
• The decision workspace
• Benchmarks overview