Buyer cases in the Allegro Message Centre are, since 28 October, the default place a buyer reports an after-sale problem to you if you sell from a business account. There are no Discussions in that channel any more: they remain only on Allegro Lokalnie and in Allegro's fulfilment warehouse. Allegro described it in its announcement of changes for buyers. For you that means two things to check: whether the team knows where to look now, and whether the script or plugin that used to pull Discussions can still see new cases.
I am writing this on 30 October, two days after the change. One inbox for everything is simpler for the buyer, so there is little to hold against the change itself. The problem is on our side: in a small company after-sale support usually rests on one person's habit and on one piece of automation nobody has touched in months. An arrangement like that does not fall over loudly. It breaks quietly.
Buyer cases in the Allegro Message Centre: what changed on 28 October
Until 27 October the path of a case looked like this: a buyer reported an after-sale problem and a Discussion appeared on your side, a separate list next to the messages. For a support team that was convenient, because it kept "I have a problem with my order" apart from "do you ship on Mondays". Since 28 October, for business accounts, that same case arrives as a thread in the Message Centre, right next to ordinary questions. There are no Discussions in that channel any more.
Discussions have not disappeared from Allegro altogether. They stay where selling has a different character: on Allegro Lokalnie and in Allegro's fulfilment warehouse. If you run both channels, from this week you have two places to watch instead of one. That is the easiest part to miss, because the new habit ("everything is in messages now") is more comfortable than the truth ("everything except two exceptions").
| Case | Until 27 October | From 28 October |
|---|---|---|
| After-sale problem, business account | Discussion | Thread in the Message Centre |
| Question before purchase | Message Centre | Message Centre |
| Selling through Allegro Lokalnie | Discussion | Discussion, unchanged |
| Selling through Allegro's warehouse | Discussion | Discussion, unchanged |
Scroll the table sideways
Now the numbers, to show what scale we are talking about in a typical store. I assume 600 orders a month and that 4 percent of them end in an after-sale case: an incomplete parcel, the wrong size, damage in transit, a request for an invoice for last month's order. Swap both of those assumptions for your own, because the share of cases depends on what you sell more than on anything else.
- cases at 600 orders a month
- 24 / mo
- cases a week with no reply
- 6
- errors in the integration log
- 0
Six cases a week is not a disaster, as long as somebody sees them. If nobody does, that is six people who wrote and got no answer, and each of them has escalation mechanisms on Allegro and a place to leave a rating. After two weeks there are twelve of them, and some come back no longer as a question but as a dispute or a rating.
The AI assistant in Allegro Help: what it answers for you
In the same batch of changes Allegro launched an AI assistant in its Help section that answers the buyer before a case goes any further. A day before the cases moved, on 27 October. I do not know its rules from the inside and I will not guess what exactly it takes over: platform announcements get updated, so before you build anything on top of it, check the current state in Allegro Help and in the terms of service.
The direction, though, is predictable, because we have already seen it on the client side. The assistant takes away the questions that have one correct answer: where the parcel is, how to send goods back, how long the right of withdrawal lasts. That is good news: traffic you were answering with a template anyway stops reaching you. The problem is what is left. What is left are cases where something has to be agreed, somebody has to be refunded, or a mistake has to be admitted. The volume goes down and its average difficulty goes up.
Three places where this change breaks the automation
Here we get into what you will not find in the platform's announcement, because this is no longer Allegro's problem but your implementation's. There are three places where a change of case channel hits automation, and none of them shouts.
First: pulling the cases. If an integration, a plugin or a script was asking Allegro for Discussions, it is still asking and still getting a response. Except that now, on a business account, that response is an empty list. From the code's point of view nothing happened: the request succeeded, there is no data. In the log it looks exactly like a week in which nobody had a problem with an order. No red entry, no alert, no failure email.
Second: the reply templates. A template written for a Discussion assumed context: it was known that this was about a specific order and about a problem, not a question before a purchase. In a single stream alongside questions that context is gone. If the automation answers everything with the same text, it will either reply too formally to "do you have this in size L" or too lightly to "the parcel arrived smashed". The first is funny, the second costs money.
Third: the response time report. If somebody at your company measures how long a reply takes, and measures it on Discussions, then since 28 October they have been getting excellent results on an empty set. A metric that measures a channel that no longer exists is worse than no metric, because an absence makes you look while a good score puts you to sleep. It is the same mechanism we wrote about with prices and stock from several sources: data nobody has marked as authoritative always ends up lying in somebody's favour.
A support audit in fifteen minutes
Below are the twelve questions I ask a client in this situation. They come in three groups: where cases land, who sees them, and whether the automation still pulls them. You answer yes, no or not sure, and the checklist turns that into a risk level and a list of things to do this week. The three questions about automation are marked as critical, because that is where a case disappears without a trace: a single "no" there is enough for the high level, regardless of the rest.
- Checklist
Support audit after the change
Twelve questions about where buyer cases land, who sees them and whether your automation still picks them up.
Where cases land
You know which place in the panel after-sale problems reported by buyers land in today.
Somebody has opened a real case after 28 October and seen what the whole thread looks like.
You know whether you also sell through Allegro Lokalnie or Allegro's fulfilment warehouse.
You have one sentence written down about where to look when a buyer says they wrote and nobody replied.
Who sees them
At least two people have access to the Message Centre and know they are supposed to look there.
Notifications about new messages reach a mailbox somebody reads the same day.
It is settled who answers cases on the days that person is away.
Once a week somebody looks at cases with no reply, not only at new messages.
Whether automation still picks them up
You know where your integration or plugin pulls cases from: Discussions, the Message Centre, or both.critical
The autoresponder or the reply templates have fired on a real case since the change.critical
You have an alert that speaks up when the number of cases pulled drops to zero.critical
You know when somebody on your side last read the list of upcoming Allegro API changes.
Result for these answers
Medium risk
10 of 24 risk points · 4 of 12 questions ticked off
Cases do get through, but they rest on one person or one habit. One holiday or one more panel change and some cases will wait days before anyone notices.
To do this week
- 01Take one case from the past week and walk it from the first message to the reply.
- 02Add that one sentence to the support instructions and send it to the team.
- 03Put the cover into next month's rota, by name rather than by department.
- 04Set up a weekly review of unanswered cases: fifteen minutes in the calendar, one named person.
- 05Ask your integration vendor outright which place it reads cases from after 28 October.critical
- 06Send a test case from a private account and check whether the automation answered.critical
- 07Add an alert on zero cases pulled within 24 hours and name who it goes to.critical
- 08Put a monthly API change review in the calendar: fifteen minutes, always the same person.
The checklist does not know your account: it is a list of questions to ask at your own company, not a verdict on Allegro. Scoring to swap for your own: “no” is 2 points, “not sure” is 1, and three questions about automation are critical, where a single “no” is enough for the high level.
How to read it matters. "Not sure" is a legitimate answer and nothing to be ashamed of: with four people in a company nobody remembers how the notifications were set up two years ago. It is, however, a task: every "not sure" turns into one concrete action on the list to the right. A low level does not mean there is nothing to do. It means two routines are left: a weekly review of unanswered cases and a monthly review of API changes, each fifteen minutes, each assigned by name.
What to check in the Allegro API before 13 November
The second change from the same period is narrower but comes with a hard deadline. The list of upcoming Allegro API changes states that from 13 November 2026 the categoryId field in POST /ingredients/parse becomes mandatory. That is the product ingredients endpoint, so it concerns a narrow group: sellers listing goods with a mandatory composition, and the tools that fill those fields in for them. If you do not sell that kind of assortment, you can move on.
If you do sell it, the question is not "will my integrator handle this", because every vendor will answer "yes" to that. It is: "do you send categoryId in that call today, and when did you check". An answer of "we will check" is fine if it comes back with a date. An answer of "that is on Allegro's side" is not, because the deadline is on your side: from 13 November a call without that field simply will not go through, and the result will be a listing you cannot publish or update.
| Question | Deadline | No answer means |
|---|---|---|
| Where do you read after-sale cases from on a business account | this week | nobody knows whether cases reach you at all |
Do you send categoryId in POST /ingredients/parse | before 13 November | a risk that some listings stall after 13 November |
| Who on your side reads the upcoming API changes, and how often | once a month | you will hear about the next change from a buyer |
Scroll the table sideways
How to set support up so the next change does not stop it
There will be a next change, because Allegro has been tidying up its panel for years and has no reason to stop. You can, however, set support up so that a channel change costs half a day instead of two weeks of silence. Six things, in the order I would do them:
- 01One inbox for every after-sale case, whichever channel it came from. If Allegro cases, emails and the phone land in three different places, every panel change means checking three things instead of one.
- 02An alert on emptiness, not only on errors: zero cases pulled within 24 hours while sales are unchanged. One rule, and it works at the next change too.
- 03Cover written down by name for the coming month. Not "the support team", but a surname, because a team does not read messages.
- 04A weekly review of cases with no reply: fifteen minutes, the same person, in the calendar. New messages announce themselves; old ones stay quiet.
- 05A monthly review of the upcoming Allegro API changes, fifteen minutes. That is where changes appear with a date, before they land.
- 06Reply templates reviewed twice a year for what the buyer already knows from other sources. That is an hour of work, and it decides the first sentence an angry person reads.
Nothing on that list needs a new tool. The first three points are decisions, the next two are calendar entries, and the sixth is an hour of reading. Technology only comes in when the volume stops matching the number of hands: that is when it pays to have your own layer next to Allegro that pulls cases and ties them to the order in your trading system. That is how our Allegro integrator for Subiekt nexo PRO works: it is a service on your side, so when the platform moves a channel, one place in the code changes rather than the whole company's process.
Two things from our own implementations, because I prefer specifics to promises. For a workwear store we built an application straight on the Allegro REST API, with no intermediary and with the code on the client's side; the first version went into production after 3 weeks, and the write-up is in the workwear store case study. For a photovoltaic roof manufacturer we launched, in 2 weeks, a chatbot on the website that takes enquiries around the clock and answers in under 2 seconds; that one was about pre-purchase traffic, but the mechanism is the same: an AI chatbot on WordPress. What is missing from both examples: neither was built to answer a complaint on your behalf. Automation is there to deliver the case to a human with the full picture, not to hide the human.
If the checklist came out at high risk and you have nobody to ask about the automation, start with a conversation. If it turns out this has to be rebuilt, the next step is an audit for PLN 699 net: a document with the architecture, the scope, the risks, a fixed price and a deadline, deducted in full from the implementation price. If fixing one request and adding an alert is enough, we will say so plainly and no audit will be needed. While you are at it, it is worth working out what all the manual work around Allegro costs, not just the cases: that calculation is in a separate post on re-typing orders.
