The complaint count was falling, but so was passenger satisfaction. That paradox was the defining feature of a project I worked on in early 2015 with a mid-sized airline catering company based in Istanbul. The firm employed 378 staff and served both charter and scheduled flights, handling between eight and ten thousand meal portions per month across its production and logistics operations. The board read the declining complaint figures as a success signal. What I found on the ground told a different story: complaints weren’t being formally logged, many were being resolved through informal channels, and some were simply not making it into the system at all. The complaint management infrastructure had become both the first and last line of defence — which is precisely why it was failing. This article defends a single argument drawn from that experience: before implementing an ERP-based complaint tracking system in airline catering operations, you must first define the responsibility boundaries between departments. Without those boundaries, every system you build will record complaints but never locate their root cause.The most deceptive feature of catering complaint management is that the accountability chain appears clear on paper but is deeply ambiguous in practice. The kitchen production department controls recipe compliance and portioning; the logistics department manages vehicles and cold-chain integrity; the flight operations team handles delivery timing and trolley loading. When a passenger files a ‘cold meal’ complaint, each of those three departments points to a different root cause. The kitchen says the food was hot when it left the facility. Logistics says the cold chain was maintained throughout transport. Operations says there was a technical delay at gate boarding. None of them are necessarily lying. The fragmentation isn’t accidental — it emerges specifically when a system tracks the complaint record rather than the complaint owner. Root cause analysis is therefore not primarily a technical problem. It is an organisational design problem that must be solved before any software configuration begins.The conventional response to this fragmentation is to assign complaint ownership to the department that receives the complaint, then hold that department accountable for reporting. The flaw in this logic becomes apparent exactly where it appears most sensible: the department receiving the complaint is simultaneously the party investigating its root cause. You have placed the judge and the defendant in the same chair. In the Istanbul project, the production team’s monthly reports attributed most temperature-related complaints to delivery delays. The logistics team’s data pointed toward packaging faults. By the third month, when we saw that 57 per cent of complaints had been coded as ‘operationally caused’ — and noted that those entries came from the operations team itself — the problem became structurally visible. To trust the numbers, you first have to ask who entered them and under what conditions. Data quality in a complaint ERP is inseparable from data governance, and data governance is inseparable from accountability structure.The first eight weeks of the project focused less on technical system requirements and more on user behaviour and data entry habits. What we observed was this: roughly a third of complaints were not entered into any formal system. They were sent as messages to a WhatsApp group used by shift supervisors, who often forgot to transfer them to the system by end of shift — or simply closed them out as ‘resolved’ without opening a record. When we timed the average completion of the existing eight-field complaint entry screen, it came to 4.5 minutes. For a staff member managing trolley logistics during a tight turnaround window, that duration is not a minor inconvenience — it is a structural barrier. The informal workaround was not laziness; it was rational adaptation. A complaint system that ignores user experience design doesn’t redirect traffic to the system — it redirects traffic to the phone. Form simplification was therefore a prerequisite for both user adoption and data integrity, and it had to come before any technical reconfiguration of the ERP modules.Without a structured analytical framework, complaint data can only tell you about frequency — not causality. The standard approach in Turkey’s airline catering sector in 2015 was to categorise complaints by type and assign a responsible department to each category. That is a reasonable starting point, but an insufficient one. The real challenge is this: the same complaint category can point to entirely different root causes, and determining which cause is operative requires cross-departmental data. Consider a temperature complaint. That complaint becomes analytically meaningful only when examined alongside the trolley’s internal temperature log, the vehicle’s cold-chain record, and the kitchen’s departure temperature entry. An ERP that cannot bring these three data sources onto a single screen is not an analysis tool — it is an archive. The approach we chose was to use the complaint record as a trigger, with linked query screens that opened automatically when a department manager logged in, presenting all operationally relevant data associated with that complaint in a single view. Building that integration required the logistics, kitchen production, and flight operations modules to share either a common database or a standardised reporting layer. Whether that technical prerequisite is in place is the first question to ask before selecting any software.The most acute tension on the management side was not technical. It was interpretive. Senior leadership had a strong tendency to read declining complaint numbers as evidence of operational improvement. Department managers, by contrast, knew that the decline reflected shrinking capture rates rather than genuine performance gains — but said so only in private. That silence reflects a gap between reporting culture and accountability structure that no software can close on its own. The real value of a complaint management system is not in reducing complaint volume. It is in making visible which department, in which process, is producing failures and at what frequency. In this light, a ‘department performance scorecard’ built on complaint data transforms a one-dimensional count into a multi-variable assessment. The right measurement questions are not how many complaints arrived, but: how many were logged accurately and on time by the responsible team? In how many cases was root cause formally identified? And how often did the same failure pattern recur within 90 days? A catering operator that measures complaint management maturity along those axes can evaluate process quality independently of total complaint volume — a capability that, as of 2015, remains largely unrealised across Turkey’s catering operations sector.For any operations director considering a similar initiative, I would put three questions before any vendor conversation. First: is the person filling in the complaint form inside or outside the accountability chain for that complaint? Second: for cross-departmental complaints, who determines root cause, and on the basis of what data? Third: is there a positive correlation between complaint reduction and passenger satisfaction index, or are these two metrics moving independently? The answers to those three questions matter more than which software platform you select. In the Istanbul project, the genuine value ultimately came not from the ERP complaint module but from the process work that redefined accountability boundaries between departments. The software made those boundaries visible. Without the boundaries, the software would have been nothing more than a more expensive filing cabinet.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 20, 2015. The English edition has been reviewed and edited by the author.