A company selling on three platforms usually has three teams, three people or three browser tabs open for one person. The work is divided by platform because that is the simplest arrangement: one person handles Allegro, another Amazon and another eBay. For a while, this looks like order. Then it becomes a problem — not because people fail to communicate, but because each queue sees only its own deadlines.
Unifying multi-platform support is therefore not about writing one instruction manual. It is about changing the priority from “by platform” to “by time remaining before the response window expires”.
Friday afternoon exposes the problem
At 4 p.m. on Friday, three cases are waiting in the inbox: an Allegro message, an Amazon A-to-z claim and an eBay dispute. The person handling Allegro sees their own queue. The person responsible for Amazon may already be off duty. No one sees all three cases together, so it is unclear which one truly cannot wait.
This is not primarily a skills problem. It is a queue design problem.
Three platforms, three different clocks
A shared process is possible, but the elements that can be standardised must be separated from those defined by each platform's rules.
| Dimension | Allegro | Amazon | eBay.com | Can it be standardised |
|---|---|---|---|---|
| Response window | 24 hours; Saturdays, Sundays and public holidays are not included in the response time | 48 hours at specific stages of an A-to-z claim; deadlines depend on the event and the market | No single fixed window for messages; seller performance metrics also matter | No |
| What can affect the account | Depends on the measure and how the case is resolved | A claim funded by the seller may affect the account | A case closed without seller resolution is part of the standard; the 2% threshold applies with a condition concerning the number of buyers | No |
| Queue priority | Time remaining before the applicable deadline expires | Time remaining before the applicable deadline expires | Time remaining before the case closes | Yes, internally |
| Decision authority | Internal monetary threshold | Internal monetary threshold | Internal monetary threshold | Yes, internally |
| Documentation | In the platform channel | In the platform channel | In the platform channel | Yes |
Allegro describes a 24-hour response time for customer questions and messages in Discussions, excluding Saturdays, Sundays and public holidays. Amazon specifies 48 hours for certain actions related to an A-to-z claim and allows 30 calendar days to appeal an awarded claim. This is not one rule for every Amazon case.
eBay.com does not base its standard solely on response time. Cases closed without seller resolution and the transaction defect rate are among the performance criteria. Exceeding 2% alone is not enough to lower the status: under the cited standard, the defects must be associated with more than four different buyers. Other eBay markets may have different conditions.
The content of a reply cannot be standardised either. Each platform decides cases according to its own procedures and documents. What can be standardised are three things: priority, internal decision authority and documentation.
One queue instead of three
The queue should be sorted by the time remaining before the applicable deadline expires, not by platform. An Amazon case opened on Friday afternoon may be more urgent than an Allegro message from the same afternoon because the deadlines are calculated differently. A platform-based team may not see this because each part of the organisation works with a different reference point.
The second element of a shared process is decision authority. If the Allegro agent can approve a return up to PLN 300, while the Amazon agent must ask the owner about every amount, the organisation has two different processes. The second one will be slower exactly where the response window is shorter.
The third element is documentation. Agreements with the customer should be recorded in the platform channel to which the case relates. A phone call or email outside the platform may carry less weight in a proceeding if the person deciding the case cannot access it.
What changing the order achieves
The following example is a modelling scenario, not data from a specific company.
Assume that a company receives 900 tickets per month: 500 from Allegro, 250 from Amazon and 150 from eBay. It operates three queues, with one person per platform, five days a week.
In this arrangement, each person handles their own stream in order of arrival. Amazon cases received on Friday afternoon may wait until Monday if the person responsible for that channel finishes work at 5 p.m. The monthly volume alone cannot show how many cases arrive at particular times or how many are subject to the 48-hour window. That requires timestamps and case-type data.
With one shared queue, cases with the shortest time remaining before the applicable deadline move to the top. Handling them takes the same number of working hours, but the order changes. This may improve the use of available working time.
It does not create hours that do not exist. If no one works on Saturday, an Amazon case may still expire before Monday. One queue organises priorities, but it does not replace staffing.
The financial perspective
Changing the sorting logic may not require a new headcount or a new tool, but that does not mean zero cost. The process must be configured, escalation rules agreed, the team trained and the visibility of deadline data checked.
Another cost comes from the lack of shared decision authority. Every escalation to the owner consumes time from a window that may last 48 hours on one platform and follow a completely different rule on another. With three platforms, escalations can multiply across three sets of procedures even when the business decision is similar.
A further cost comes from uncovered days. A queue alone does not solve this. If a deadline runs on Saturday, the company must separately decide whether to provide coverage or accept the risk of the case being decided without its participation.
What one process consists of
A shared process for three platforms can be based on three elements:
- one queue prioritised by the time remaining before the applicable deadline expires;
- shared internal financial authority, as long as it does not conflict with platform procedures;
- one documentation rule: correspondence and agreements are recorded in the platform channel.
The fourth element — coverage of days and hours — requires a staffing or service decision. It cannot be replaced by a procedure alone.
Marketplace365 states that it supports multiple platforms and markets and is available seven days a week. These are service provider statements, not an independent benchmark. Before comparing the offer with an internal model, check the current market scope, SLA and contract terms on the Marketplace365 website.
Where a shared process works — and where it breaks
A shared process makes sense when:
- the team works from one task list rather than three independent panels;
- the system shows the market, case type and time remaining before the applicable deadline expires;
- internal decision thresholds are clear and the agent knows when to escalate;
- the company measures time remaining before the window expires, not only average response time.
The process breaks down when:
- the team is divided solely by platform;
- the company introduces a shared queue but keeps five-day staffing while actively selling on platforms with weekend deadlines;
- agreements with customers are made outside the platform channel;
- shared internal authority is confused with operator rules.
Multi-platform chaos does not come only from the number of platforms. It comes from sorting tickets by where they came from while platforms measure different stages of a case by different clocks. One queue can organise priorities. The other half of the solution is a deliberate decision about who handles cases while the deadline is still running.