# What teams build in Prowork for vendor and carrier scorecards > What scorecard flows in Prowork actually do: on-time and in-full rates, SLA adherence by lane, and supplier compliance measured from source records. Source: https://parabola.io/reports/vendor-carrier-performance --- ## What gets built Scorecarding is the smallest category here by flow count and among the more consequential, since each of these flows replaces a recurring argument about whose shipments were late with a number that both sides can look at. Of the 139 companies whose usage went into this study, 63 run some version of this work in Prowork, spread across 297 flows that were active in the last 90 days. Grouping those flows by what each one actually does gives the breakdown below. Flows by build patternCarrier Scorecard Reporting99Vendor Compliance & Scorecarding99Production & Sourcing99flows active in the last 90 days Carrier Scorecard Reporting, Vendor Compliance & Scorecarding and Production & Sourcing are level at 99 flows each. The grouping follows what a flow does rather than which team happens to own it, which is why one company often turns up in several of these rows at once, and the businesses building the most of them work in apparel, health and beauty, and food and beverage. ## Three of them in detail Three of those flows in more detail, described by what each one does rather than by who built it. Company names are withheld, so each is identified only by the size and category of the business running it. **A $1B+ logistics provider.** Builds a carrier performance scorecard for drayage shipments, measuring pickup, delivery, scheduling, milestone update timeliness, empty returns, and proof-of-delivery SLAs. Helps operations teams identify service failures, account for valid exceptions, and manage carrier accountability with consistent weekly reporting. Built on Google Sheets, Snowflake. **A $50M+ software company.** Pulls open sales orders, job records, and related purchase order/receiving data from an external manufacturing/ERP API, then flattens BOM inputs and matches them to job line items. Built on API. **A $500M+ apparel brand.** Monitors shipment on-time delivery against expected transit times across carriers, facilities, regions, and lanes. Highlights late-delivery patterns and carrier mix trends so transportation teams can identify service issues, hold carriers accountable, and improve customer delivery performance. Built on Email, Looker, email attachments. ## What they have in common Read enough of these flows and the same shape keeps appearing. A flow pulls the same records from each system that holds a version of them, standardizes whatever identifiers are needed before those records can be joined at all, applies the comparison or the calculation as explicit logic, and then labels every row with an outcome so that the handful needing attention can be routed to whoever is able to act on them. What differs from one flow to the next is which single step genuinely calls for interpretation. Reading a supplier PDF, resolving a merchant name that never quite matches the ledger, or deciding which category a vague line description belongs in are all handled by AI steps inside the flow, while the matching rules, the tolerances and the thresholds around them stay explicit, since those are the parts a controller or an auditor will eventually want to read for themselves. Most of these run on a schedule or fire from a trigger rather than waiting for someone to remember to open them, and that is largely what separates a report describing what happened last month from a process that surfaces the problem while there is still time to do something about it. The sources they read from are worth noting, because they are rarely the tidy ones. Across the documented flows in this category the most common inputs look like this: Systems these flows read fromGoogle Sheets10Email attachments5SharePoint4Direct API3Email3OneDrive3Redshift2Snowflake1documented flows reading each source Email attachments and spreadsheets sit at the top of that list on most pages, which is a fair description of where operational data actually lives once it leaves a system of record. ## Scorecard prompts to start from - [Flexport SLA reporting](https://parabola.io/use-cases/flexport-sla-reporting) — An SLA is the transit time a carrier or forwarder committed to on a given lane. - [Track production orders against sourcing reality](https://parabola.io/use-cases/production-sourcing-reporting) — Production and sourcing reporting sets the plan against reality: what was ordered from each factory, on what dates, at what cost, compared with what the supplier has actually cut,… - [Carrier scorecard reporting](https://parabola.io/use-cases/carrier-scorecard-reporting) — A carrier scorecard grades every carrier you use on the same metrics over the same period: on-time delivery, damage and exception rates, cost per shipment, and whatever service… - [Track average days to return delivery](https://parabola.io/use-cases/average-days-to-return-delivery) — Return delivery tracking measures the time between a customer starting a return and the unit physically arriving back at the warehouse, broken out by carrier, lane, and return… - [Vendor chargebacks reporting](https://parabola.io/use-cases/vendor-chargebacks) — A chargeback is a deduction a retailer takes from what it owes you, assessed when a shipment breaks one of their compliance rules — late delivery, wrong carton label, missing… - [Vendor scorecard reporting](https://parabola.io/use-cases/vendor-scorecard-reporting) — A vendor scorecard grades each supplier on how reliably they deliver what was ordered, when it was promised. - [Wholesale OTIF scorecards](https://parabola.io/use-cases/wholesale-otif-scorecard) — OTIF — on time, in full — is how a retailer grades a supplier: did the order arrive inside the delivery window, and did it arrive complete.