Base is one of the best order management systems in the Polish e-commerce stack. Over a thousand integrations, automation rules, label printing, stock sync. A seller running one shop gets a tool that just works.
A fulfillment operator isn’t a seller. The operator serves other sellers: 5, 10, 30 clients in parallel. Each client has his own pricing, his own configuration, his own expectations, his own legal status, his own reporting needs.
That’s where Base starts to crack.
This isn’t a critique of the platform. Base does exactly what it was designed to do. But if you use it as the central hub of your entire fulfillment operation, sooner or later you’ll hit each of the five walls described below.
Gap 1. No multi-tenant
The trouble starts with architecture.
Base works per account. One account, one data scope. A fulfillment operator typically has one BL account and connects client sales channels (stores, marketplaces) to it. All orders end up mixed in a single space.
There’s no native concept of a “fulfillment client”. You can’t say: “these orders belong to client A, those to client B, and each one sees only his own”.
What operators do today:
A separate Base account per client. Sounds reasonable up to 5 clients. Past that, chaos. With 10 clients, you juggle 10 logins, 10 integration setups, 10 subscriptions. Subscription cost: 1,000–3,000 PLN per month. Management cost: several hours per week.
One shared account with tags as a separator. Works up to three clients. Past that, tags get lost in 50,000 orders, reports become unreliable, and orders regularly route to the wrong warehouse.
The fix requires a layer over Base that understands the concept of a fulfillment client and isolates his orders, stock, and history. This is the first gap, but linked to every following one.
Gap 2. No per-client pricing
Base has no built-in mechanism for billing between operator and client. You can issue invoices from another system, but Base on its own won’t tell you: “client X had 23 pallets for 15 days, 430 outbound orders, 18 returns. Invoice: 4,230 PLN”.
All pricing logic must live outside Base. In practice, in the operator’s head and in an Excel sheet.
What operators do today:
Tags in Base, CSV reports, Excel, manual rate multiplication. 15–25 hours of admin work per month (see 5 billing mistakes). For 8–10 clients. Each new client adds 2–3 hours.
Alternative: a custom script on the Base API. Works great for 3 months. Then the developer leaves, the client requests a change, nobody wants to touch the code.
The fix: a system with native per-client pricing. Each client has his own rate set (storage, intakes, shipments, returns, premium for special zones, ad-hoc services). The system bills automatically from Base data.
Gap 3. No client portal
An e-commerce client wants to see how much stock he has, where his orders are, what came back as returns. In Base, you can grant him access to your account. Then he sees data of all your other clients. That disqualifies the option from a GDPR and basic-hygiene standpoint.
The lack of an isolated end-client view is probably the biggest Base gap from a 3PL perspective.
What operators do today:
A weekly PDF by email. A phone call to “how much stock do I have?”. A shared Google Sheet with limited access. None of these scale or build trust.
An operator with 12 clients and 800 orders per month measured a 55% drop in inbound emails after rolling out a portal (see Client portal for 3PL). That’s not an aesthetic argument. That’s an operational one.
The fix: a dedicated client portal, authenticated, synced with Base, showing only the data for that one client. With white-label branding for premium clients.
Gap 4. Inbound notifications still over email
The client has a delivery tomorrow. He needs to notify you: when the truck arrives, how many pallets, which SKUs, the CMR number. Base has no inbound notification form. There’s no system that accepts, stores, and routes that data to a specific client.
Notifications end up in email. Some land in spam, some get lost in threads about other topics, some arrive on Saturday at 11 PM. The warehouse finds out about the delivery late or not at all.
What operators do today:
Google Forms (free but no integration). A dedicated email address. The phone. Each of these solutions sits apart, each requires manual transcription into the system.
The fix: inbound notifications as part of the client portal. The client fills the form (date, pallet count, SKUs, CMR). The notification lands in the system tagged with client and date. The warehouse sees it on the delivery calendar. Automatic notifications for both sides.
Gap 5. No ticket system
The client has a problem. An order shipped to the wrong address. An item arrived damaged. The invoice doesn’t add up. He emails support@.
The email lands in the inbox. Someone replies during the day. The client follows up. After three exchanges, nobody knows what stage the case is at. The email gets mixed with 20 other threads. No SLA, no priority, no history.
Base has order notes, but that’s not a support system. A note exists in the context of one order, not one client. No ticket statuses, no deadlines, no response-time metrics.
What operators do today:
Email. In the better case, Freshdesk or Zendesk (200–500 PLN per month), but with no integration to fulfillment-client data. The support clerk has to open two systems to answer one question.
The fix: tickets integrated with the client portal. The client opens a ticket, sees its status, gets notified on every reply. You see all tickets per client with full context (his stock, his orders, his invoices, his history). SLA measured automatically.
What to do: add a layer
Temptation one: replace Base with something else. Bad path. Base handles marketplace integrations, sales automations, and labels. Few systems on the market do this better. Dropping Base means a 6-month migration project and a loss of team competence.
Temptation two: build everything yourself. Real cost: 200 thousand PLN in year 1, 60 thousand PLN per year afterward. Plus developer risk. Sensible for a 3PL with 50+ clients and unique requirements. For 5–30 clients, no.
Temptation three, the right one: add a layer over Base. A system that reads from BL, fills in what BL doesn’t do (multi-tenant, billing, portal, inbound notifications, tickets), and doesn’t require you to drop existing infrastructure.
| Gap | Solution |
|---|---|
| Multi-tenant | Client isolation in one system |
| Per-client pricing | Automatic billing per client |
| No portal | Portal with white-label branding |
| Inbound notifications | Notification module with alerts |
| Tickets | Per-client support system |
That’s exactly FulBill. A business layer over Base that closes five gaps at once. It reads BL via API, changes nothing in your existing setup, and adds what BL doesn’t have.
Next step
Pick the most painful gap for your business. If you’re losing clients, it’s the portal. If you’re losing margin, it’s billing. If you’re losing time, it’s tickets or inbound notifications. Focus on one. Onboarding takes 5–10 working days.
Feature details at /features, pricing at /pricing. To see a demo for your specific Base setup, book a call.