A claim in a store that sells through Baselinker usually starts with the question “which order is this even about”, not with what went wrong. One customer writes from Allegro, another by email, a third calls and reads out a parcel number. Somebody in support opens Baselinker, searches by surname, finds three orders from that person and guesses which one it is. When someone searches for a ticket system wired into Baselinker, they usually have a dozen mornings like that behind them and want the ticket to know, from the moment it is created, which order it belongs to.
This post is about how that wiring works from the inside, when an off-the-shelf helpdesk for an online store is enough and when a custom panel pays off, and what each of them really costs. I write it as somebody who builds such panels, so wherever a ready-made tool does the job, I will say so outright.
A ticket system wired into Baselinker - how it works
The core is simple: a customer’s ticket should be created already attached to a specific Baselinker order, rather than attached by hand afterwards. Everything else follows from that one assumption.
In practice it looks like this. The customer opens a claim or return form and enters an order number or an email address. The panel asks Baselinker over the API for that person’s orders, shows a list with dates and products, and asks them to pick one. From that moment the ticket carries the full context underneath it: what was bought, for how much, when it shipped, with which carrier, from which sales channel. Support opens the ticket and sees all of it on one screen instead of hopping between tabs.
The other side of the same wiring is the write-back. When a ticket moves to “return accepted” or “claim upheld”, the panel can add a tag to the order in Baselinker, change its status or attach a note, so the person packing parcels and the person issuing credit notes see the same thing without an extra email. What can be written to Baselinker and what is read-only I broke down separately in the post on Baselinker API and automation - here it is enough to know that orders, statuses and notes go both ways.
The third element, the one most often forgotten, is history. A ticket attached to an order stays with it for good. A year later, when the same customer comes back with another matter, support can see that the previous claim was upheld and a replacement was sent. Without the wiring, that knowledge lives in somebody’s mailbox and leaves together with the employee.
What helps: before you start comparing tools, list the last five claims and, for each one, note how long it took just to establish which order it concerned and what was in it. That is the cost the Baselinker wiring removes entirely - the rest is extras.
Claims and returns - what the panel needs to know about the order
Handling returns in Baselinker and handling claims are two different processes, even though both begin with the same order. A return is simpler: the customer sends the goods back, the store checks their condition, the money goes back. A claim has variants: repair, replacement, price reduction, rejection with a justification. A good ticket system does not throw both into one bucket; it runs each down a separate path with its own statuses and its own response deadline.
From the order, the panel needs a handful of specific things, not the whole database:
- Order lines, so the customer can point at the product the matter concerns rather than describe it in words.
- Sales channel, because a claim from Allegro has its own deadlines and its own dispute window, while a claim from your own store follows general consumer law only.
- Ship date and carrier, so that a “parcel damaged” ticket immediately tells you whom to file the transport claim with.
- Payment method, because a refund travels one route for a bank transfer and another for a payment made on the marketplace.
The rest of the data can stay in Baselinker. The panel should show it when needed, not copy everything into itself - that, incidentally, is the same mistake that ruins many integrations: moving whole orders across instead of asking for them when required.
Off-the-shelf helpdesk or a custom panel
Honesty is due here: ready-made helpdesks are good at what they were built for. A multi-channel inbox, reply templates, assigning cases to people, response time on a counter. If your problem is chaos in email, a subscription tool solves it faster than I can write the first screen of a panel.
The trouble starts at the seam with Baselinker. Most helpdesks have no ready integration with Baselinker, and those that do usually show the order as a preview, with no write-back and no return logic of their own. A claim is still “a message with an attachment”, not a process with stages. At a few dozen tickets a month that does not hurt. At a few hundred orders a month across several sales channels, support ends up keeping a spreadsheet on the side anyway, to track deadlines and statuses the helpdesk cannot handle.
A custom panel makes sense exactly when three conditions hold at once:
- Tickets follow repeatable paths with stages and deadlines, rather than being loose correspondence.
- Every ticket must be firmly attached to a Baselinker order, with a write-back.
- Somebody outside support - the warehouse, accounting, the owner - needs to see the state of cases without asking.
If one condition holds, a ready-made helpdesk plus a simple integration is enough. If two, it is worth running the numbers. If all three, the panel pays for itself sooner than it seems, because the cost today sits in support hours nobody counts. I laid out the same decision for wholesale in the post on an off-the-shelf versus a custom B2B platform; the mechanics of the choice are identical.
What helps: before you choose, check one thing in the ready-made helpdesk - whether it can change the order status in Baselinker once a case is closed. If it cannot, somebody will do it by hand for every ticket, and that is the whole calculation.
What cannot be skipped in either variant
A few things have to be set up regardless of whether you take a ready-made tool or a custom panel, and it is better to know about them before the start.
A Baselinker API key with limited permissions. A ticket panel does not need access to purchase prices or product editing - it needs to read orders and write statuses and notes. Issuing a full key “because it is simpler” is the most common mistake I see in these deployments.
Unambiguous customer identification. The same person buys on Allegro under one email, in the store under another, and calls from a third phone number. The panel must be able to find the order by number, by email and by parcel number, because the customer will give whatever they have to hand.
Request limits. Baselinker caps the number of API calls, so a panel that re-fetches orders from scratch every time a screen refreshes will start getting refusals at peak hours. The fix is well known - a short-lived cache and fetching only what changed - but it has to be planned, not bolted on after the first outage. What those refusals look like from the inside I described in the post on why Baselinker stops downloading orders.
What it costs and what you get
A ready-made helpdesk is a monthly subscription that depends on the number of agents and channels, plus possibly a separate fee for the integration through a middleware tool. The price lists are public, so I am not copying them here - they change more often than this post.
A custom ticket panel added to what you already have - a WooCommerce store, a company website, a Baselinker account - is fixed-bid work for me, usually within the 5,000-10,000 PLN net range. What typically fits in that amount: a ticket form with order selection from Baselinker, two paths (return and claim) with their own statuses and deadlines, a support panel with a case list and history, write-back of status and a note to the order, email notifications to the customer when the stage changes. What pushes the quote up is the number of roles (support, warehouse and accounting each seeing different things), additional channels beyond Baselinker, and automatic document generation - I wrote more about how such things move the price in the post on the cost of a custom web application.
Always in writing, always before the start, with a list of what is in scope. If it turns out after a conversation that your five claims a month are handled fine by a ready-made helpdesk, I will say so - and instead of a panel you will get advice on which tool to use. If you want it priced on your own case, describe how a claim runs at your company today, from the ticket to the refund, and I will send back a scope with a quote.
Can such a panel be built without a store of your own, on Baselinker alone? Yes. A ticket panel does not need WooCommerce - it needs a Baselinker account with API access and somewhere to run, which is ordinary hosting or a VPS. Your own store is convenient because the form can sit inside the customer account, but when you sell only through marketplaces, the panel stands on its own and gets its own address, which you send to customers in the message after purchase.
Building an application, a panel or an integration rather than a website? I write B2B systems to order - backends, APIs, client panels, billing modules. Tell me what it has to do and a quote with scope and a date comes back.