GoatLabelsGoatLabels

Blog

20 Questions to Put in a Shipping Software RFP

Twenty RFP questions for parcel shipping software, grouped by carriers, integration, billing, operations, and contract terms, with a simple scoring method.

A shipping software RFP works when every question forces an answer you can verify in a demo or a trial. The 20 questions below are grouped into five areas: carriers and rates, integration, billing and finance, daily operations, and contract and support. Ask each vendor the same questions in the same order, require a yes, no, or partial plus one sentence of evidence, and score the answers against weights you set before the responses arrive.

What should a shipping software RFP cover?

It should cover the five areas where shipping tools differ in ways that cost you money or labor after you sign. Feature lists can look alike across vendors. The differences may show up in whose carrier rates you use, how orders get in and tracking gets out, how charges reach your books, what happens at the pack station when something fails, and what you are committed to.

Before writing questions, write down three facts about your own operation, because they decide which answers matter:

  1. How orders leave your system today: a file export, an API, or a person retyping.
  2. Whether you hold your own carrier contracts and need to keep using them.
  3. Who reconciles shipping cost, and against what document.

A vendor cannot give a useful answer to a vague requirement. "Must integrate with our ERP" invites a yes from everyone. "Must accept a CSV of open sales orders with our PO number as a reference and return tracking numbers keyed to that reference" does not.

Which questions should you ask about carriers and rates?

Ask whose rates you will be buying on, because that determines both your cost and your flexibility.

  1. Which parcel carriers and service levels are available from our origin locations, and which require a separate carrier account?
  2. Can we connect our own carrier accounts and negotiated rates, or do we buy on the vendor's rates only?
  3. Is the quoted rate the amount we are charged, and which surcharges (fuel, residential, additional handling) are included in the quote versus billed later?
  4. How are carrier re-weigh and dimension adjustments handled, and where do they appear?

Question 2 may be the one that narrows your list fastest. If your negotiated rates are better than a vendor's pooled rates on your main lanes, a tool that cannot use your accounts is a secondary tool at most. If you have no contract, the question reverses: you want to know how the vendor's rates compare on a sample of your real parcels, which you can test with a rate request for last month's shipments.

Which integration questions separate a real fit from a workaround?

The ones that ask for the mechanism, not the logo. A named connector tells you little until you know which fields it moves and in which direction.

  1. How do orders get from our ERP, WMS, or order system into your product: native connector, file import, or API? Name the method for our specific system.
  2. Which fields can we carry on each shipment (PO number, customer ID, cost center), and do they appear on exports, invoices, and API responses?
  3. How does tracking get back to our system: automatic write-back, webhook, export file, or manual copy?
  4. Does the API support test keys, an idempotency key on label purchases, and a published specification we can read before signing?
  5. What are the API rate limits, and are API calls metered or priced separately?

For question 7, ask the vendor to show the write-back happening on your system's version, not a slide. For question 8, a public specification lets your developer estimate the work before procurement is finished. If you expect to build the connection yourself, the ERP shipping integration guide describes the file and API patterns, and the shipping API for developers page shows what a documented label API looks like.

What should finance ask about billing and cost reporting?

Finance should ask how a single label becomes a line in the books, and how long that takes.

  1. What is the full pricing model: subscription, per-label fee, per-user fee, markup on postage, or a mix? Provide a cost for our stated monthly volume.
  2. How do we pay for postage: prepaid balance, card on file, or invoice with terms? When is each label charged?
  3. Can we export every charge with our reference field, the carrier, the service, and the date, and how are later adjustments tied to the original shipment?
  4. Can costs be separated by customer, location, or department, and are separate balances or sub-accounts supported?

Question 12 decides how much manual work month-end takes. If the export carries your PO or customer reference on every line, including adjustments, cost allocation is a join in a spreadsheet. If it does not, someone matches tracking numbers by hand. The parcel spend management page covers what that export should contain.

What operational and support questions matter at the pack station?

The questions about failure matter most, because the demo only shows the path where everything works.

  1. What happens to a batch when one address fails validation: does the batch stop, or does the bad row get reported and the rest proceed?
  2. How do labels reach our printers, and is unattended printing supported for our printer models?
  3. How are multi-carton orders handled: one label per carton, and one reference across all of them?
  4. What support channels exist (phone, email, chat), during which hours, and is there a written response-time commitment?

Then the contract terms:

  1. What is the minimum term, the notice period, and the cost of leaving early?
  2. Is there an uptime commitment, and what is the remedy if it is missed?
  3. Which security and access controls are available: single sign-on, user roles, audit logs, and data export on termination?

How do you score the answers?

Score each answer 0, 1, or 2 (no, partial, yes), multiply by a weight you set before reading responses, and treat any must-have that scores 0 as a disqualifier regardless of the total. Setting weights first stops a strong demo from quietly rewriting your priorities.

Here is a worked example with hypothetical numbers, shown only to illustrate the arithmetic. A distributor weights the five areas to total 100 points and scores two fictional vendors.

Area Weight Vendor A average (0 to 2) Vendor A points Vendor B average (0 to 2) Vendor B points
Carriers and rates 25 2.0 25.0 1.0 12.5
Integration 30 1.0 15.0 2.0 30.0
Billing and finance 20 1.5 15.0 1.5 15.0
Operations 15 2.0 15.0 1.0 7.5
Contract and support 10 1.0 5.0 2.0 10.0
Total 100 75.0 75.0

Points are the weight times the average divided by 2. In this example the totals tie at 75, which is the useful lesson: the total alone does not decide. If the distributor marked "use our own carrier accounts" as a must-have and Vendor B answered no to question 2, Vendor B is out despite the tie. If the must-have was automatic tracking write-back and Vendor A answered no to question 7, the result flips.

Two more rules keep scoring honest. Have at least two people score independently and reconcile differences in a meeting. And convert every "partial" into a written note about what is missing, because partial answers are where implementation surprises come from. A ready-to-edit version of these questions with the scoring grid is in the shipping software RFP template.

Where GoatLabels fits

GoatLabels is a fit for some answers on this list and a clear no on others, and it is better to see both before you send the RFP.

Where it answers yes: USPS, UPS, FedEx, and DHL are rate-shopped on every parcel from one account. Orders come in through 13 store connectors, a CSV import of up to 500 rows per file that names the row and field of any error without failing the batch, or a REST API with live and test keys, an Idempotency-Key, signed replayable webhooks, and an OpenAPI 3.1 specification. Postage is paid from a prepaid wallet, and every label and re-weigh adjustment is a dated ledger entry carrying your reference. Multi-carton orders produce one label per carton under the same reference. Pricing is public on the pricing page: a free plan with 50 shipments a month, or a flat $40 a month for unlimited shipments, with no contract.

Where it answers no: you cannot bring your own carrier accounts or negotiated rates. There are no native ERP, WMS, or EDI connectors and no automatic write-back into an ERP, so anything beyond the 13 stores is CSV or API work on your side. There are no sub-accounts or per-client balances, no SLA, no SSO, no phone support (support is email plus an in-app assistant), no LTL or freight, and no retailer compliance labels.

If questions 2, 13, 19, or 20 are must-haves for you, GoatLabels will not pass your RFP and an enterprise system is the right shortlist. If your must-haves are multi-carrier rates without a contract, a clean cost ledger, and an API or file route you control, it belongs on the list.