A 3PL operator near Gdańsk. 12 clients, 800 orders per month. Every day, 2–3 client emails: “how much of this SKU do I have left?”, “did order 8421 ship?”, “send me the March invoice, I can’t find it”.
Each email is 3–5 minutes: check Base, screenshot, reply. Times 12 clients, times 5 working days. The admin clerk spends 2.5 hours daily on this.
After deploying a client portal, email volume dropped by 55% in six weeks. The clerk recovered 14 hours per week. One large client who was considering switching providers extended the contract for 2 years. His stated reason: “For my CFO, the portal is proof we’re working with a serious operator”.
A client portal isn’t a luxury for a 3PL. It’s a tool that cuts handling cost and increases stickiness. The question isn’t whether. The question is what exactly it should contain.
What a portal is NOT
Three things operators confuse with a portal:
Access to your Base account. The client sees data of all your other clients. Disqualifying. Breaks NDAs and GDPR.
A weekly PDF report by email. A PDF is a document, not a portal. The client will still ask for current stock.
A shared Google Sheet with view rights. A patch, not a solution. No isolation, no audit trail, no scaling past 10 clients.
A portal is a live data view of the client’s data. Current stock. Orders from the last 90 days. Invoices. Inbound notifications. Tickets. Everything authenticated, isolated per client, branded for your 3PL.
What the portal MUST have
The list of things without which the portal is decoration:
Stock per SKU. Updated live from Base or WMS. Client logs in and sees what’s on hand. Right now. Not yesterday.
Order history. Last 90 days, filterable by status (new, in fulfillment, shipped, delivered, cancelled). Client searches for order 8421 and finds it in 5 seconds.
Invoices. Every invoice from the past 12 months. PDF download. Payment status. Client doesn’t email “did you send the February invoice?”.
Inbound notifications. Form: delivery date, pallet count, SKU list, CMR number. Client fills it once, the warehouse gets a notification and sees everything in the delivery calendar. No more emails on Saturday at 11 PM.
Returns. Return list with current status (received, under assessment, restocked, scrapped). Client sees the journey of every return without phoning.
Tickets. Per-client support system with history, status, response SLA. Email is not a ticket.
What it does NOT need
Operators often overshoot here and build a portal the client doesn’t want:
Product catalog editing. The client manages his catalog elsewhere: in Base, Shopify, PrestaShop, wherever his store lives. Your role is the warehouse and shipping, not catalog management.
Requirement that the client has his own Base account. The client doesn’t need to see BL. Your portal pulls data from your BL account and shows the client only what’s tied to his brand.
Full analytics and BI. The client has other tools for that. Three simple reports are enough: turnover per SKU, rotation, monthly operating costs.
Integration with the client’s accounting system. PDF invoices cover 95% of cases. If the client wants API access, that’s a separate conversation, not a portal default.
A subdomain per client with white-label branding for everyone. A shared portal under your domain with per-client isolation covers 80% of cases. White-label only for premium B2B clients who want to hide that they use a third-party 3PL.
Numbers. Build vs subscribe
The operator faces a choice: build the portal or buy a finished one?
Build it yourself:
| Line item | Cost |
|---|---|
| Full-stack developer, 4 months | 60,000–100,000 PLN |
| UX/UI design | 8,000–15,000 PLN |
| Hosting + infra, year 1 | 6,000–12,000 PLN |
| Maintenance after launch (40 h/mo) | 4,000–6,000 PLN/mo |
| Year 1 total | 120,000–200,000 PLN |
| Each year after | 48,000–72,000 PLN |
Plus risk: the developer leaves, the codebase is a one-of-a-kind artifact, the next developer refuses to maintain it. That’s the reality of 70% of these projects.
FulBill subscription:
Plan with client portal, 10 clients, white-label branding, inbound notifications, tickets, invoices: from 1,100 PLN per month. Yearly: 13,200 PLN. Onboarding: 5–10 working days.
Year 1 difference: 110–190 thousand PLN. Year 2 difference: 35–60 thousand PLN. No code-loss risk, no maintenance, no hiring.
The case for building exists if you have 50+ clients and very specific requirements no off-the-shelf product covers. Then a custom portal can make sense. For a 3PL with 5–30 clients, it doesn’t.
When the portal becomes mandatory
Four signals you need it today:
5+ active clients. Below that, you can survive on email. Above it, your admin starts to rot.
B2B or premium e-commerce clients. They expect tools at the level of their own business standards. No portal = signal you’re a small shop without process.
Team under 5 people. Every admin hour is one taken from operations. The portal recovers 2–3 hours daily.
You’re competing on sales. A larger 3PL has a portal. The client compares. Without one, you’re a tier below regardless of physical service quality.
Next step
Write down how many stock-related emails you get per week. Multiply by 5 minutes per email. Multiply by 4 weeks. Multiply by your admin clerk’s hourly cost.
That’s your monthly cost of having no portal. Compare to a 1,100 PLN subscription.
FulBill ships the client portal as part of the platform, ready to deploy in 5–10 working days. Live stock from Base, inbound notifications, invoices, tickets, branding per client. Details at /features#portal or book a call.