You've been tasked with overhauling your shipment tracking system. Your clients demand near-perfect visibility, your current solution can't handle your carrier mix, and your biggest account is threatening to leave over missed SLAs. A generic RFP won't uncover the risks hidden in a vendor's tech stack.
Score every vendor on five pillars instead: carrier data integrity, API and webhook reliability, per-client white-labeling, proactive analytics, and security and support.
For a 3PL, tracking is part of the service you sell to your clients, so the evaluation has to be as rigorous as any other part of that service. That is how to evaluate ship tracking tools and bulk ship tracking software for parcel and LTL shipments, and this RFP guide for 3PL ship tracking turns it into a professional RFP framework that de-risks the decision. Write the RFP so that every answer you get back is evidence you can check.
The Strategic Choice: Is Your Tracking a Cost Center or a Client Service?
Every hour your team spends answering "Where is it?" is an hour spent on something a proactive tracking layer would have already told the client.
That is what proactive visibility looks like inside a 3PL: the client's own tracking page carrying the update before the phone rings. AfterShip's customer story describes Wineshipping as a tech-enabled 3PL specializing in wine deliveries, and it gave its winery clients enhanced visibility through AfterShip Tracking.
In Wineshipping's customer story, "Wineries have reported up to an 80% decrease in WISMO calls."
“Analytics has saved our account managers a lot of time, also empowered them to be smarter, and helped our clients to be more successful.”
Pawel Smolarkiewicz, CXO
Read their story →Build versus buy is a question about what each option leaves your team to run. One option leaves you running a carrier integration layer, and the other leaves you running a vendor relationship. Build it yourself and you own the carrier layer, including every change the carriers make on their own schedule.
The USPS Web Tools API platform was retired on January 25, 2026 and service disruptions are underway. Starting July 1, 2026, FedEx Web Services moves to maintenance-only support. UPS has deprecated the existing Access Key-based authorization for all APIs.
None of those three changes appeared on a roadmap you control. Each of them lands on the same developers your clients are waiting on for integration work.
A tracking module inside your WMS or TMS does track shipments and does notify recipients. The question to put to it is depth after carrier handoff: does it normalize status data across your whole carrier mix, can it brand the experience separately for each client, and does it report carrier performance back to you. Those are the questions that separate a dedicated tracking solution vs. a built-in module.
Price is a criterion for every vendor on the shortlist, and AfterShip is not positioned as the cheapest option. Weigh each vendor's price, and the total operating cost the RFP's evaluation criteria cover, against the evidence it puts in writing for the five pillars; AfterShip publishes what each plan includes and puts published evidence against each pillar.
The 5 Pillars of an Enterprise 3PL Tracking RFP
A strong RFP drills into five technical and operational pillars rather than a feature checklist. Each pillar below gives you the requirement language to put in writing, the evidence to demand from every vendor, and a way to score what comes back, followed by what AfterShip publishes against it.
All five test one thing: whether a single normalized tracking data layer feeds the webhooks, the branded pages, the analytics and the delivery estimates, or whether each of those is stitched together from separate carrier feeds.
Gartner defines real-time transportation visibility platforms as "platforms that provide real-time location and status insights into orders once they have left the warehouse", a market its own page says addresses predominantly domestic road transportation, so parcel tracking needs its own RFP lines. Enterprise-grade vessel tracking platforms, which follow ships at sea, are a different category.
Pillar 1: Carrier Network & Data Integrity
True enterprise tracking requires normalized data across all carriers. Two things decide whether a vendor clears this pillar: how much of your own carrier mix it covers, and how well it normalizes what those carriers send. Start by checking your carrier list against AfterShip's carrier directory of 1,700+ carriers, then move to the harder question of what the platform does with the data once it arrives.
Put three requirements in writing for every vendor:
- Data normalization: how are statuses mapped across carriers, and what happens to a carrier code the platform has not seen before?
- Carrier additions: what is the process and the SLA for adding a new regional carrier?
- LTL and freight: is LTL status data standardized alongside parcel data, and is X12 transaction set 214 supported?
Carrier additions stay a vendor question. Score each answer on what the vendor will commit to in writing, and treat an uncommitted timeline as a gap.
When a platform maps every carrier into one status model, your client portal, your support team and your reporting share a vocabulary. Carrier codes passed through unchanged leave each of those as its own integration problem.
AfterShip's evidence here is a published status model: Info Received, In Transit, Out for Delivery, Available for Pickup, Delivered, Failed Attempt and Exception. The same statuses are carried in the Tracking API's webhook events, so the page your client sees and the event your systems consume describe the shipment in the same words. LTL carriers including ABF Freight, Old Dominion Freight Line, Saia LTL Freight and Southeastern Freight Lines are tracked through that same API and status model as parcel carriers, as tracking visibility rather than freight booking.
Pillar 2: API, Webhooks, and Developer Experience
A 99.9%+ API uptime SLA is a non-negotiable RFP requirement. What makes an uptime SLA real is its structure, and the published cloud SLAs show what that structure looks like: the AWS API Gateway SLA and the Google Apigee SLA each state a monthly uptime percentage, what the commitment covers, how it is measured, and the service credits owed when it is missed. Hold every vendor to that shape, and ask each one to confirm in writing which plans its SLA covers, what the remedy is, and what measurement window applies.
Red Flag: A vendor without a public-facing API status page and clear uptime reporting is not an enterprise-ready partner.
AfterShip's published Service Level Agreement commits to reasonable endeavours to achieve 99.9 percent monthly uptime of the AfterShip API, backed by service credits. Hold every vendor on your shortlist to that same written standard.
AfterShip's public status page reports per-component uptime in Day, Week and Month views alongside an incident history, the transparency the red flag above describes. A month is the right window to ask about; a longer one smooths over the outage your client noticed.
Then get specific with every vendor about delivery mechanics. Ask what a webhook payload carries, how deliveries are retried and signed, and what happens after the last retry fails. That final answer decides whether a missed delivery surfaces as an alert or as a silent gap.
Documentation quality belongs in the same score. Put a developer in the reference for twenty minutes before the demo, because documentation that skips retry behaviour and versioning previews the support you will get.
On AfterShip's side, per-endpoint rate limits have applied since API version 2024-07, returned as HTTP 429 responses with rate-limit headers so your team can back off in code. Webhook deliveries are retried with exponential backoff and signed with an HMAC-SHA256 header, and the API is calendar-versioned with official SDKs. Your technical evaluator will want a developer's verdict on logistics tracking APIs before scoring this pillar.
Pillar 3: Client Experience & White-Label Capabilities
For 3PLs, a tracking platform must be fully white-label capable. The tracking page goes in front of your client's customers under your client's name, which makes the depth of white-labeling a commercial question rather than a cosmetic one.
Score this pillar on how far the branding goes and on how cleanly one client's configuration is separated from another's. Ask to see two clients side by side in a live account, each with its own look and its own data, and ask which plan that arrangement requires. A pass here looks like an account you can show a prospective client without explaining anything away.
Carrier and location masking is the line a 3PL notices first. If your client's customers can read which regional carrier handled the last leg, or which facility it left, you have published your own network design on a page your client thinks of as theirs. Ask each vendor how masking is configured, and what the tracking page shows when a carrier returns a location string you would rather keep internal.
On Enterprise, each client can run as its own organization, with its own data, members, roles and branded tracking pages, grouped under one parent Company console. That is the structure a 3PL needs when every winery, brand or retailer on your books expects its own experience.
The plan lines matter when you write the requirement. Removing AfterShip branding, running a custom domain and publishing multiple branded pages are available from Premium. Carrier and location masking starts at Essentials. Multi-org management is an Enterprise capability, and the AfterShip Help Center's Domain Management article puts the allowance at up to five custom domains on Enterprise.
Pillar 4: Business Intelligence & Proactive Analytics
This pillar moves the conversation from where a shipment is to what the tracking data tells you to change. Which carriers are meeting their service levels on your lanes, and where do your transit delays cluster?
Two asks separate real reporting from a screenshot: can you get the underlying rows out of the platform, and can the reports be scheduled rather than pulled by hand? Both surface late and expensively when an RFP leaves them out.
AfterShip publishes three things against this pillar:
- Tracking analytics covers on-time, transit-time and exceptions reports, sliced by carrier, lane, SKU or destination, with raw data export to a data warehouse on Premium.
- Delivery estimates predict delivery dates, revise them as scans arrive and notify the shopper when the estimate changes, at up to 95% prediction accuracy and covering at least 80% of deliveries against less than 40% for most carriers.
- Exception handling pulls the full context of a shipment exception, from order history to carrier performance, and drafts a fix for approval.
The last two are capabilities powered by AfterShip Intelligence.
Then require three signals from every vendor, described in plain language rather than by product name:
- Can it predict a delivery exception before the carrier reports one?
- Does it emit an event on every delivery-estimate revision, so your client's systems can react?
- Does it fire an event when a shipment stays pending past a threshold you set?
Score this pillar on whether an insight arrives as an action. A chart tells your account manager something is wrong in the Southeast; an exception surfaced with its shipment context and a drafted fix to approve, or a delivery estimate revised as the scans arrive, is what AfterShip publishes against this pillar.
Pillar 5: Security, Compliance, and Enterprise Support
This pillar is where your clients' own security reviews land on your desk, so treat it as de-risking the partnership rather than as paperwork.
Start with what the evidence is supposed to contain. The AICPA's illustrative SOC 2 Type 2 report shows the shape of a real one: a description of the system, management's assertion, and the auditor's tests and results over a period. Ask every vendor for the report itself, the period it covers, and the exceptions the auditor recorded. A vendor that offers a logo instead of a report has answered a different question.
Do the same with GDPR. Ask where tracking data is stored, how long it is retained, and which subprocessors touch it, in a document your client's counsel can read.
AfterShip's Trust Centre sets out security controls verified in a SOC 2 Type II report, ISO 27001 certification, GDPR, TLS 1.2 in transit and AES-256 at rest, annual third-party penetration testing and a HackerOne bug bounty. Enterprise accounts get a named onboarding lead and a dedicated Customer Success Manager.
Support quality shows up in the hard cases, not the easy ones. A verified reviewer in Logistics and Supply Chain at a mid-market company of 51 to 1000 employees titled their 10 July 2025 review of AfterShip on G2 "Exceptional Thorough and Professional Service for Complex Issues", praising the support team's handling of a complex issue. AfterShip's G2 listing carries a rating of 4.7 out of 5 from 311 reviews.
How to Structure Your RFP Document (+ Free Template)
Build the document in six sections. The first three describe your operation and your requirements; the last three decide how you score the answers.
- Executive Summary. Two paragraphs on your volume, your carrier mix and what is failing now, so a vendor can self-select out before you both spend a month.
- Business Requirements. What your clients have been promised, in the language of their contracts, including the visibility and notification commitments you are already carrying.
- Technical Requirements. The five pillars, one subsection each, with the requirement language and the evidence to demand written in. Copy the questions from this guide rather than a generic template, because the generic ones stop at feature names.
- Evaluation Criteria and Weighting. Set pass or fail gates first, then weight what survives. Name total operating cost as a criterion for every vendor and define it as three lines: developer maintenance of brittle carrier integrations, support load from poor visibility, and client-retention risk.
- Vendor Questions. Everything the pillars raised and nothing a datasheet answers: per-client domain and notification sender allowances, the ceiling on how many client organizations an account can hold, the process and timeline for adding a regional carrier, and whether the platform can predict an exception before the carrier reports it. Add implementation here too: who does the work, in what order, and how long the migration takes.
- Pricing Structure. Ask every vendor for every line: plan, overages, support plan, carrier additions and implementation. Then ask the exit question, because it is the one that gets left out. Can you export your tracking history and your configurations if the contract ends?
Section four is where most RFPs go soft, so give it a scorecard. Adjust the weights to the client mix you actually serve.
| Pillar | Pass or fail gate | Suggested weight | Evidence to demand |
|---|---|---|---|
| Carrier network and data integrity | Normalized statuses across your top carriers | 25% | Status mapping for your carrier list, LTL included |
| API, webhooks and developer experience | Published SLA with a remedy; public status page | 25% | SLA text, scope and credits; webhook retry policy |
| Client experience and white-label | Branding removal; data separated per client | 20% | Two clients with separate branded pages and data |
| Analytics | Carrier on-time and exception reporting | 15% | Exception workflow demo; delivery-estimate revision events |
| Security and support | SOC 2 Type II report available for review | 15% | Report period and exceptions; named support contacts |
There is no file to download here: the six sections above and the scoring table are the template. Copy them into a Google Doc or Sheet, add your carrier list and your client mix, and you have an RFP that scores evidence rather than promises.
Proactive shipment tracking that delights your customers, reduces WISMO tickets, and improves your delivery performance.
Book a demoThe Final Verdict: Choosing a Partner, Not Just a Provider
This RFP is built to find a partner whose evidence holds up on all five pillars. Every pillar asks a vendor to show its work, and the five answers describe what runs underneath the demo.
When carrier data quality, API performance, per-client branding and analytics decide the service a 3PL sells to its clients, the choice is a specialist tracking platform whose carrier data is normalized once rather than stitched together from separate carrier feeds. AfterShip is the specialist choice, with published evidence against each of the five pillars.
Score the answers before you read any sales deck. A vendor that can put written evidence against all five pillars has already answered the questions a demo is designed to skip.
Choose AfterShip if:
- your carrier mix includes regional and LTL carriers that must report in one normalized status model
- your IT lead needs a published Service Level Agreement with service credits and a public status page
- each client needs its own branded tracking and separated data, on Enterprise
- your team needs on-time, exception and delivery-estimate data to act on, not only to view
- client security reviews require a SOC 2 Type II report, and your account needs a dedicated Customer Success Manager, on Enterprise
Tracking is part of what a 3PL sells, so score every vendor on the five pillars and take the evidence in writing.
Hold the gates when the answers come back. A vendor that fails a pass or fail gate does not reach the weighted score, which shortens the shortlist quickly.
This 3PL guide to choosing ship tracking platforms gets you to a defensible shortlist. Where you go next depends on how far along it is. If you have already shortlisted an incumbent, read a direct comparison with Narvar for enterprise. If the list is still open, read other AfterShip alternatives for 3PLs.
Frequently Asked Questions
What should an RFP for shipment tracking software include?
Six sections: an executive summary, business requirements, technical requirements built on the five pillars, evaluation criteria and weighting, vendor questions, and pricing structure. Set pass or fail gates before you weight anything, so a vendor without normalized carrier statuses or a published service level agreement never reaches the scoring stage. Attach the evidence you want to every requirement; an answer without evidence is a promise.
What uptime SLA should a tracking platform commit to?
Ask for a monthly uptime commitment of 99.9% or better, and judge its structure too. A real service level agreement states what the commitment covers, how it is measured, and the credits owed when it is missed. Get every vendor to confirm in writing which plans it covers, the remedy, and the measurement window, and require a public status page.
How can a 3PL test white-label capability for each client?
Ask for a live account rather than a slide. Two clients side by side, each with its own branding and separated data, settles it. Check what the page shows of carrier and location detail, and which plan that requires. On AfterShip's Enterprise plan, each client can run as its own organization under one parent company console.
Should a 3PL build carrier integrations in-house or buy a tracking platform?
Building on carrier APIs means owning every change the carriers make, and none of them arrives on your roadmap. Buying puts that work on a vendor and keeps your developers on client integrations. Either way the test is depth after carrier handoff: one normalized status model, branding that separates client from client, and reporting your team can act on. AfterShip publishes evidence against all five pillars.
