“The customer called three times about the same complaint”: what gets built for after-sales in an application in Algeria in 2027, single ticket, priority, deadlines, escalation, returns and credit notes, customer space

“The customer wrote on WhatsApp, then called, then e-mailed. Three people noted the same fault in three notebooks, the fridge that is not cooling waits behind an invoice question, and nobody knows who is handling it.” Overflowing after-sales is not a patience problem, it is a construction: an inbox knows neither the customer, nor the order, nor the urgency, nor the deadline. This guide describes what gets built so that a complaint exists only once and is handled in the order that matters: a single ticket whatever the channel, a priority that comes from an impact by urgency grid, response and resolution deadlines the application watches, named assignment and automatic escalation, returns and credit notes linked to the order, a customer space that answers instead of the phone, and five figures on Monday.

Symloop13 min read
“The customer called three times about the same complaint”What gets built so that a complaint exists only once, whatever the channel: a single ticket, a computed priority, watched deadlines, an assignment, an escalation, a return or a credit note, a customer space that answers instead of the phone, and five figures on MondayCOMPLAINTS · AFTER-SALES · RETURNS · 2027“The customer calledthree times aboutthe same complaint”What gets built so that a complaint exists only once, whateverthe channel: a single ticket, a computed priority, watchedWHATSAPP, A NOTEBOOK, THREE CALLSand nobody knows where it standsONE TICKET, ONE STATE, ONE DEADLINEand a customer who reads instead of callingsymloop.com

Short answer. Every intake, WhatsApp, call, e-mail, customer space, courier, is matched to the customer by phone and to the order, and there is only one ticket per problem: the second contact reads the state instead of opening a file. Priority comes from an impact by urgency grid written by the manager, not from the voice on the phone, and it sets two deadlines, first response and resolution, which run, pause while waiting for the customer, and trigger an automatic escalation when passed. The ticket is assigned to a person, its states are written and dated, its actions, visit, part, exchange, credit note, are linked to the order and to stock. It closes on the customer's confirmation or after three days of silence, and every ticket carries a coded cause. The customer space shows the state and receives replies, and on Monday five figures say whether after-sales holds and where to act. Six weeks, the first without code.

This guide is for the manager of an online shop, an equipment distributor, an installer or a carrier whose complaints arrive through every channel and get lost, the founder settled in France who learns about their customers' problems in Algiers once they are already angry, and the person who wants a queue and deadlines rather than a WhatsApp inbox. It does not repeat how a customer stays unique across channels, described in the customer file guide, nor how the WhatsApp agent replies within its window, described in the WhatsApp agent guide; it describes what gets built around the complaint itself, and it extends our software engineering page.

One complaint, three channels, one ticket

The figure follows a single complaint, a fridge delivered the day before that is not cooling, arriving through three channels in the same day, and what the application does with it hour by hour.

Figure 1 · A single complaint arrives by WhatsApp, then by a call at the counter, then by e-mail with the requested photo. The phone matches all three to the same customer and the order to the same product: one ticket, not three. The priority comes from an impact by urgency grid written by the manager, and sets two deadlines, first response and resolution, which the application watches and shows as bars. States carry the time and the author, and closure waits for the customer’s confirmation. The data is a constructed example.

At 9:12, a WhatsApp message; the number matches the customer and yesterday's order, and a ticket is opened. At 11:40, the customer calls the counter to ask where it stands; the same number leads to the same ticket, whose state the employee reads instead of noting a second time. At 14:05, an e-mail with the requested photo; it is attached to the ticket and lifts the wait. One ticket, three channels, and the customer never had to repeat.

Priority comes from a grid: high impact, the product is unusable; high urgency, food is at stake the same day; the cell gives P1, and P1 sets a first response under two hours and a resolution under seventy-two. States follow one another with their time and author, qualified by Amel, assigned to technician Nadir, waiting for the customer's photo, resolved by replacement two days later, closed after confirmation. The two bars at the bottom compare actual with target: eighteen minutes and fifty-one hours. The data is a constructed example.

«Three arrivals do not make three tickets: the phone matches the same customer, the order the same product, and the second call reads the state instead of reopening a file.»
01

After-sales that holds, in five layers

The single ticket is the layer that avoids the three notebooks; priority and deadlines are the one that puts the urgent first.

Figure 2 · The accented layer is what inboxes do not have: a priority that comes from a grid and not from a voice, and deadlines that run. Without it, after-sales handles whoever shouts loudest, and the fridge that is not cooling waits behind the invoice question.

Intakes. WhatsApp, counter call, e-mail, customer-space form, courier on site: every intake is matched to the customer by phone and to the order, following the customer file guide; an intake without an identified customer stays an intake, not a ticket. Single ticket. One ticket per problem, not per message: product, order, warranty, attachments following the photos guide, exchange history; a second contact reads the state. Priority and deadlines. An impact by urgency grid written by the manager, three priorities, a first-response and a resolution deadline per priority, paused while waiting for the customer; this is the accented layer.

Handling. Assignment to a person or a team, following the rights described in the roles guide; written states; automatic escalation to the manager when a deadline is passed; automatic reminder to a waiting customer, through the right channel following the notifications guide; dated actions, visit, part, exchange, credit note. Resolution and measurement. Closure on the customer's confirmation or three days of silence; return and credit note linked to the order, the credit note following the rules described in the quote and invoice guide and the return moving stock following the stock guide; one-word satisfaction; five figures a week and first cause.

02

Six real situations, and what the application does

The six situations found in almost every after-sales service we take over, and the construction that settles them.

Figure 3 · The first two rows are settled by the single ticket and the grid; the next two by assignment, escalation and the waiting state; the last two by the link with the order, stock and credit note, and by coded causes. None is settled by a more patient person on the phone.

The first two rows are settled by the single ticket and the grid: the phone leads to the same ticket, and the urgent goes first because a cell says so. The next two are settled by named assignment, escalation and the waiting-customer state, which pauses the deadline instead of counting a delay that is not one. The last two are settled by the link with the order, stock and credit note, and by the cause coded on every ticket, which turns five faults seen one by one into the first cause of the week. None is settled by a more patient person on the phone.

03

One complaint, in six team gestures

What the person receiving the complaint does, in order, and why the second gesture changes the order of the whole queue.

Figure 4 · The accented step takes ten seconds and changes the order of the whole queue: choose impact and urgency in a grid, and let priority follow. The sixth step is the one always skipped and worth the most: one coded cause per ticket, and on Monday you know that thirty-one percent of complaints come from the carrier.

Identify: phone, customer, order, product; the application proposes the existing ticket if there is one. Qualify: choose impact and urgency in the grid, in ten seconds; priority follows, and the deadlines with it; this is the accented step. Assign to a person or a team; the deadline runs. Handle: visit, part, exchange, credit note; every action is dated and visible to the customer; waiting-customer state if you need them.

Resolve and confirm: a message to the customer through the intake channel, and closure on their confirmation or after three days of silence. Code the cause: one cause per ticket, chosen from a list written in the first week, damaged delivery, product defect, picking error, delay, information; it is the step always skipped and worth the most, because it feeds Monday.

«Priority is not the customer's mood on the phone: it is a cell of a written grid, and it sets two deadlines the application watches.»
04

The after-sales board on a Tuesday morning, and the week's five figures

The figure shows the queue as the team sees it, by state, and the five figures the manager reads on Monday.

Figure 5 · The after-sales board on a Tuesday morning: five state columns, cards with priority, age and owner, and a dashed P1 ticket that passed its first-response deadline and was escalated to the manager; it blinks until someone answers. The week’s five figures, first response, resolution, reopened tickets, tickets per hundred orders and first cause, are what the manager reads on Monday. The data is a constructed example.

Five columns, new, qualified, assigned, waiting customer, resolved to confirm, and cards with their priority, age and owner. A dashed P1 card passed its first-response deadline; it was escalated to the manager and blinks until someone answers. Waiting-customer cards carry their automatic reminder, and resolved cards their automatic closure after three days of silence.

The week's five figures: median first response, median resolution, reopened tickets, tickets per hundred orders, and first cause. The first two say whether deadlines hold; the third says whether you really resolve or close too fast; the fourth scales after-sales to the activity; the fifth says where to act upstream, here packaging or the carrier, following the orders cancelled at delivery guide. They are read on the manager's dashboard, following the real-time dashboard guide. The data is a constructed example.

05

Seen elsewhere: incident management and market support tools, and what carries over

Three ideas carry over as they are. The impact by urgency grid, common practice in IT incident management, where priority is the cell at the intersection of the two and each organisation sets its own levels; what carries over is a priority that comes from a written grid, not from a voice. Deadlines per priority, first response and resolution, paused while waiting for the customer; what carries over is a deadline that runs and escalates, not a date looked at sometimes. The multichannel single ticket of market support tools; what carries over is matching by phone, because in Algeria the customer writes on WhatsApp then calls, and e-mail comes last.

What those practices do not decide for you: your impact and urgency levels, your deadlines, your cause list, and who is escalated to; the project's first week answers that, and the manager signs. Market support tools remain the right choice when your rules fit theirs; custom starts when the ticket must talk to the order, stock, the credit note and the courier in the same application.

06

The rules of after-sales that holds

Six rules, written in the first week. One ticket per problem, matched by phone and order. Priority comes from the grid, never from the voice. Two deadlines per priority, which run, pause while waiting for the customer, and escalate. One named person per ticket, and reassignment in case of absence. The return and credit note are linked to the order and move stock. One coded cause per ticket, and five figures on Monday.

And one rule of method: closure belongs to the customer, by confirmation, or to time, by three days of silence; never to the employee eager to shrink the queue.

07

Six companies, and the ticket that was missing

Six situations composed from projects we meet; the names are generic and the figures are examples.

  • An appliance shop in Algiers, home delivery. Complaints arrived on three WhatsApp numbers and a notebook. The construction: single ticket matched by phone, P1 to P3 grid, technician visit assigned from the ticket. Repeated calls for the same fault stopped in the first month; deliveries follow the delivery platform guide.
  • A parts distributor in Oran, three hundred retailers. Parts returns were never reconciled with credit notes. The construction: return linked to ticket and order, warehouse receipt that issues the credit note and updates stock.
  • A founder in Marseille, online shop in Algiers. They discovered complaints in public reviews. The construction: customer space with ticket state, code login following the code login guide, five figures readable from Marseille; remote management follows the shop from France guide.
  • A solar installer in Sétif. Post-installation faults were handled by phone, without a trace. The construction: ticket per installation, grid with high urgency when production is zero, customer photos attached; the trade is described in the solar installer guide.
  • A marketplace in Constantine, third-party sellers. The buyer complained to the platform, which forwarded to the seller by e-mail. The construction: ticket shared between platform and seller, seller's deadline watched, escalation to the platform; the model is described in the marketplace guide.
  • A carrier in Annaba, damaged parcels. Same cause, seen parcel by parcel. The construction: coded cause, first cause of the week, alert to the packaging lead when it passes a threshold.
08

The 2027 calendar

Six weeks for a company that already receives complaints through every channel; the first week passes without code.

Figure 6 · Six weeks, and the first without code: the grid, the deadlines and the cause list are the manager’s decisions. The third week is accented because it is what puts the urgent first and makes lateness blink; before it, after-sales is a list.

Week 1, rules: impact by urgency grid, deadlines per priority, states, cause list, who is escalated to, closure and return rules; signed by the manager. Week 2, intakes and single ticket: WhatsApp, call, e-mail and customer space matched to customer and order, one ticket per problem, attachments. Week 3, priority, deadlines and assignment: grid applied, deadlines that run and pause, named assignment, automatic escalation, reminders.

Week 4, returns and credit notes: return linked to ticket and order, warehouse receipt, credit note issued, stock updated, exchange. Week 5, customer space and board: the customer reads the state and replies from their space or WhatsApp, the board by state for the team. Week 6, measurement: five figures a week, coded causes, first cause, Monday review with the manager, in the spirit of the report described in the monitoring guide. Every week ends with a demo, following the delivery without breakage guide.

09

What makes after-sales fail

Five causes, seen in applications we take over. The inbox as queue: no customer, no order, no priority. The ticket per message: three tickets for one fault, and three contradictory answers. Priority to the voice: whoever shouts goes first. The deadline that does not run: a date looked at sometimes, never an alert. Closure by the employee: the queue shrinks, customers call back.

And one cause of method: not coding the cause, because it is ten more seconds per ticket; without it, after-sales treats symptoms all year and never changes the packaging.

10

Frequently asked questions

The questions managers and founders ask when they describe after-sales that overflows.

How do you stop a customer opening three complaints for the same fault?
By matching every intake, WhatsApp, call, e-mail, customer space, to the customer by phone and to the order, and having only one ticket per problem. When the customer contacts again, the application leads to the existing ticket and the employee reads the state instead of noting a second time. The customer never has to repeat.
How do you decide which complaint to handle first?
With an impact by urgency grid written by the manager: impact says whether the product is usable, urgency says what happens if you wait. The cell gives the priority, P1 to P3, and the priority sets the deadlines. Priority never comes from the voice on the phone.
What are response and resolution deadlines for?
So that a ticket is not forgotten: the deadline runs from opening, pauses while waiting for the customer, and triggers an automatic escalation to the manager when passed. The week's medians say whether the team holds its deadlines; the deadlines themselves are set by the manager per priority.
How do you handle returns and credit notes?
The return is linked to the ticket and the order; its receipt at the warehouse issues the credit note and updates stock, so a product taken back by the courier does not vanish between the truck and the warehouse. An exchange follows the same mechanics with a new delivery.
Can the customer follow their complaint without calling?
Yes, from a customer space where they log in by code and read the ticket state, answer requests, a photo for example, and confirm the resolution. The same information reaches them by WhatsApp. The goal is that the second call no longer has a reason to exist.
Why code a cause on every ticket?
Because it is what turns complaints handled one by one into the first cause of the week: damaged delivery, product defect, picking error. When a cause passes a threshold, the manager and the supplier are alerted, and you act on packaging or the carrier rather than on the symptom.
How long does it take to set this up?
Six weeks in the typical calendar: one to write the grid, the deadlines and the causes, one for intakes and the single ticket, one for priority, deadlines and assignment, one for returns and credit notes, one for the customer space and the board, one for measurement. The duration depends on the number of channels and whether a single customer file exists.
Send us a month of complaints, we measure duplicates and delays

Manager in Algeria or founder in France: we build after-sales where the complaint exists only once and goes in the order that matters

Symloop builds and takes over applications in production for companies in Algeria and founders settled in France: WhatsApp, call, e-mail and customer-space intakes matched to customer and order, single ticket per problem, impact by urgency grid and deadlines per priority, named assignment, automatic escalation, reminders, returns and credit notes linked to order and stock, customer space with state and replies, board by state, coded causes, five figures a week. Code and rules in your repository; a demo every two weeks.