Municipal AI call centers in Turkey: tender analysis and solution-line design

What AI actually solves in a municipal call center, and what it does not

Municipal call centers and citizen solution lines operate against demand that is unevenly distributed across the day, largely repetitive, and does not fit into office hours. Requests about water outages, refuse collection times, property tax payments, marriage appointments, required documents, zoning status and park maintenance faults cluster on particular days; on a day with snowfall or an infrastructure failure, line capacity becomes meaningless. Artificial intelligence targets a capacity and channel problem here, not a competence problem.

What AI genuinely solves for a municipality falls into four headings: absorbing first contact during peaks without a queue, keeping the line open outside office hours and at weekends, consolidating non-telephone channels such as web, WhatsApp and social media into a single flow, and closing out the repetitive questions that make up the bulk of total volume without staff involvement. All four are measurable, contractible and can be tied to acceptance criteria.

What AI does not solve is where most projects fail. Recording a request correctly changes nothing in the field if no team exists to act on it. If institutional knowledge is scattered, if the fee schedule appears differently in three places, or if the boundary of responsibility between departments is unclear, a language model does not resolve that ambiguity; it propagates it in a confident tone. Interpretation of legislation, exception requests involving discretionary authority, and sensitive requests that could become formal complaints must remain with humans by design.

Esenyurt Municipality's announcement of 3 June 2026 illustrates this distinction well. The announcement describes the system's function in the words "Yapay zeka destekli altyapı sayesinde gelen başvurular otomatik olarak analiz edilerek ilgili müdürlüğe yönlendiriliyor" (incoming requests are automatically analysed and routed to the relevant department). What is promised is not resolution of the problem but delivery to the correct unit without error or waiting. Nevşehir Municipality's communication assistant, announced on 12 July 2026, sits in the same information and routing layer; it operates on the municipal website, WhatsApp, Telegram, Instagram and Facebook, runs 24 hours a day seven days a week, and offers support in more than 80 languages.

• Solves: peak-hour waiting, out-of-hours availability, multi-channel fragmentation, staff load on repetitive questions.
• Does not solve: field team capacity, unclear boundaries between departments, outdated or contradictory internal information.
• Should not attempt: exception requests requiring discretionary authority, interpretation of legislation, statements with legal effect.
• Must be measurable: first-contact resolution rate, human handover rate, average handling time, routing accuracy.

Task decomposition: not one AI customer representative but four separate jobs

The most expensive design mistake in municipal solution-line projects is assigning the entire workload to a single large model. In tender documents and internal correspondence the work usually appears as one line item, named "yapay zeka müşteri temsilcisi yazılımı" (AI customer representative software) or "yapay zeka asistan yazılımı kiralama hizmeti" (AI assistant software rental service). Technically, that single line item decomposes into at least four separate jobs of differing difficulty: intent classification and routing, knowledge lookup against an approved source set, request and complaint ticket creation, and summarisation of a long interaction for staff.

These four jobs do not have the same model requirement. Determining which department an incoming message concerns is a classification problem over a bounded label set, and a small model handles it with high accuracy. Supplying information such as a fee schedule, a required-documents list or opening hours is not a generation problem but a retrieval problem: what matters is not model size but the approved document set behind it. Retrieval-augmented generation is mandatory only for this second group.

Cost control comes precisely from here. The bulk of volume on a municipal line is classification and repetitive knowledge lookup, and both can be served by small and medium models. The portion that needs a large model consists of complex requests involving statutory exceptions or several departments at once, and those form a small share of total volume. In an architecture where each task is designed as a separate model and a separate budget line, cost per request falls markedly against a single-model architecture.

The second benefit of decomposition is the boundary of responsibility. When a task is defined as a separate component, its error rate can be measured separately, given its own threshold, and handed to a human on its own when needed. In a monolithic assistant you can establish that a wrong answer was given, but not which layer failed, which makes both correction and contractual acceptance testing impossible.

Accuracy and responsibility: wrong information harms the citizen

Wrong information on a municipal solution line produces a different outcome from a commercial customer-service error. A citizen relies on an incomplete document list, travels to the municipality and cannot complete the transaction; is hit with a late-payment surcharge because a payment deadline was misstated; or never applies at all because they were told they were ineligible. What these three scenarios share is that the error materialises on the citizen as lost time, money or entitlement. Accuracy is therefore not a quality target in the project but a design constraint.

The first condition of accuracy is an approved source set. The knowledge pool from which the model may produce answers must be limited to documents the institution itself has published and that have identifiable owners: the council resolution setting the fee schedule, the service standards table, required-document lists, official announcements and departmental internal circulars. Every document must have an owner, an effective date and a person responsible for updates. Ownerless documents must not enter the pool, because if it is unclear who removes the superseded version when a tariff changes, the system will keep stating stale information confidently.

The second condition is that the system can say it does not know. Language models fill gaps by default; the desired behaviour on a municipal line is the opposite. An answer should be produced only when a match exists in the approved source set, and where there is no match the model must return an explicit statement of insufficiency and move the flow to a human rather than answering from general knowledge. This behaviour is achieved not by asking politely in the prompt but with a control layer that halts generation when no source match is found.

The third condition is that the human handover threshold is defined in advance and numerically. The handover decision should be tied to three separate signals: classification confidence falling below threshold, no match found in the approved source set, and the topic falling into a predefined list of sensitive subjects. Topics such as social assistance applications, declarations of health status, legal disputes, staff complaints, and death or burial procedures must not be answered automatically regardless of how confident the model is.

The fourth condition is traceability. Every answer given to a citizen must be recorded together with the document, and the version of that document, on which it was based. If a request later becomes the subject of an objection, the institution must be able to answer the question of which document the information came from. This record is the only concrete evidence available both for internal audit and for evaluating contractor performance.

• Approved source set: every document needs an owner, an effective date and an update owner; no ownerless documents in the pool.
• Insufficiency response: where no source matches, the model must not guess and the flow moves to a human.
• Handover threshold: define three separate triggers, namely low confidence, no source match, and sensitive-topic list.
• Topics never answered automatically: social assistance, health declarations, legal disputes, staff complaints, burial procedures.
• Traceability: log every answer with the source document and document version it relied on.

KVKK: a citizen request contains personal data

Almost every request reaching a municipal solution line contains personal data. Citizens volunteer their name, address, telephone number, subscriber number, registration number and at times information about their health condition or need for social assistance. The municipality is the data controller for this processing, and the obligations under Law No. 6698 (KVKK, the Personal Data Protection Law) apply regardless of whether the processing is carried out by a call center agent or by software.

Article 4(2) of the Law lists the principles that must be observed when processing personal data. Subparagraph (ç) states that processing is subject to the principle of being "İşlendikleri amaçla bağlantılı, sınırlı ve ölçülü olma" (relevant, limited and proportionate to the purposes for which they are processed). In solution-line design this principle converts directly into an engineering constraint: the prompt sent to a model must carry the minimum data needed to perform that task. Routing a request to the relevant department does not require the citizen's name, address or telephone number; the subject text of the request is sufficient.

In practice this means separating the prompt layer from the record layer. Identity and contact details are written to the institutional system that creates the request ticket, while they are stripped from the text sent to the model through masking or removal. The text the model sees should be sufficient for classification and summarisation and insufficient to identify the person. Where special categories of data under Article 6 of the Law, such as health status, criminal conviction or religious belief, appear in a request, that request should be removed from the automated flow and passed directly to authorised staff.

The legal basis for processing must also be established. Article 5(2) lists the situations in which processing without explicit consent is possible; subparagraph (a) covers "Kanunlarda açıkça öngörülmesi" (being expressly provided for by law), and subparagraph (ç) covers processing that is "Veri sorumlusunun hukuki yükümlülüğünü yerine getirebilmesi için zorunlu olması" (mandatory for the data controller to fulfil a legal obligation). Recording a request within the municipality's remit and a contractor's use of that data for analytics do not rest on the same legal basis, and the two must be assessed separately.

The duty to inform must be discharged in the channel itself. Article 10 requires the data controller, at the time personal data are obtained, to inform data subjects of the controller's identity, the purpose of processing, the parties to whom data may be transferred and for what purpose, the method and legal basis of collection, and the rights listed in Article 11. In practice this means access to the privacy notice at the first message of the WhatsApp line, at the opening of the web chat window, and in the greeting announcement of the voice channel.

On security and retention, Article 12(1) obliges the data controller to take "uygun güvenlik düzeyini temin etmeye yönelik gerekli her türlü teknik ve idari tedbirleri almak" (all necessary technical and administrative measures to ensure an appropriate level of security) in order to prevent unlawful processing of and unlawful access to personal data and to ensure their safekeeping. The contract must state explicitly how long interaction transcripts are retained, who may access them, whether they may be used for model training, and how they are destroyed at the end of the service. If a service hosted abroad is to be used, the cross-border transfer regime in Article 9 of the Law must be assessed separately.

• Goes into the prompt: subject text of the request, category information, and neighbourhood-level location if needed.
• Must not go into the prompt: full name, national ID number, telephone, full address, subscriber and registration numbers.
• Requests found to contain special categories of data are removed from the automated flow and routed to authorised staff.
• Retention period, access rights, prohibition on use for model training and destruction method must be written into the contract.
• The privacy notice must be reachable at the entry point of every channel, and the channel list recorded in the data inventory.

Municipal AI tender: the structure of IKN 2026/743700 and what lowest-price means

Municipal AI call center projects in Turkey now run through concrete tender documents, and the structure of those documents directly determines the technical design of the project. The work titled "Yapay Zeka Asistan ve Yapay Zeka Müşteri Temsilcisi Yazılımı Kiralama Hizmeti" (AI assistant and AI customer representative software rental service) of Bahçelievler Municipality's IT Department was published under tender registration number IKN 2026/743700 for a tender date of 11 May 2026 at 10:00. The work is procured under the open tender procedure of Article 19 of Law No. 4734 (Kamu İhale Kanunu, the Public Procurement Law), which defines the procedure as "Açık ihale usulü, bütün isteklilerin teklif verebildiği usuldür" (the open tender procedure is the procedure in which all tenderers may submit bids).

The other conditions in the notice describe a one-year, single-contractor operation closed to foreign suppliers. The duration of the work is 365 days from the start date, and work begins within 7 days of contract signature. The notice states "İhaleye sadece yerli istekliler katılabilecektir" (only domestic tenderers may participate) and "Konsorsiyum olarak ihaleye teklif verilemez" (bids may not be submitted as a consortium). The bid validity period is 90 calendar days, and the R coefficient used in the threshold-value calculation is given as 0.78 for the "Diğer Hizmetler" (Other Services) category.

The most consequential clause in this notice for technical design is that the economically most advantageous tender will be determined on the basis of lowest price. Article 40(2) of Law No. 4734 provides: "Ekonomik açıdan en avantajlı teklif, sadece fiyat esasına göre veya fiyat ile birlikte işletme ve bakım maliyeti, maliyet etkinliği, verimlilik, kalite ve teknik değer gibi fiyat dışındaki unsurlar da dikkate alınarak belirlenir" (the economically most advantageous tender is determined either on price alone, or on price together with non-price factors such as operating and maintenance cost, cost effectiveness, efficiency, quality and technical merit). When an administration chooses the first of these two routes, quality and technical merit carry no score in bid evaluation.

The consequence is this: in a lowest-price tender, the only document that carries quality is the technical specification. An accuracy threshold, a human handover rule or a retention period that is not written into the specification produces no advantage for any tenderer at evaluation and cannot be demanded during the contract period either. The approved source set, insufficiency behaviour, sensitive-topic list and traceability log described in the sections above must therefore enter the specification as minimum technical requirements rather than as scored bid criteria.

Lowest-price evaluation also affects the tenderer's own cost arithmetic directly. A tenderer working on infrastructure whose per-use unit price is unknown will bid for a 365-day service with an uncertainty margin added, and that margin pushes the bid upward. A tenderer using infrastructure whose input and output unit prices are published per model can instead distribute the expected monthly request volume across task types, build a predictable cost base and narrow that margin. By the same token, the administration can state its volume assumptions explicitly in the approximate cost study.

Measurement follows the same logic. In a lowest-price contract the only lever the administration retains is the acceptance and payment stage, so metrics must be defined in the specification with numeric thresholds. The minimum set to track is four: first-contact resolution rate, human handover rate, average handling time and citizen satisfaction. These must be reported not only in aggregate but broken down by task type and channel; otherwise the success rate on high-volume easy questions conceals failure on complex requests.

• First-contact resolution rate: share of requests closed without human handover; report broken down by task type.
• Human handover rate: the target is not zero, and a high handover rate on sensitive topics is correct behaviour.
• Average handling time: measure first response time and ticket creation time separately.
• Citizen satisfaction: report scores separately for flows that were handed over and those that were not.
• Routing accuracy: the count of inter-department returns is the most honest indicator of classification quality.

Where LLMTR fits in a municipal solution-line project

LLMTR is a gateway platform that makes the task decomposition described in this article buildable through a single integration. A contractor or a municipal IT team that wants a small model for classification, a medium model for knowledge lookup and a large model for complex requests calls all of them through one OpenAI-compatible /v1 surface instead of signing a separate provider contract and writing a separate integration for each. Switching models comes down to changing the base URL and the model identifier, which makes trying models during a pilot inexpensive.

The per-unit key and spending cap structure maps directly onto municipal organisation. Separate API keys can be issued for the call center, the web chat and the WhatsApp channel; each key gets its own rate limit, its own spending cap and its own usage report. When one channel sees unexpected volume growth the cap engages and the budget does not overrun from a single point. The same structure also makes usage distribution by department visible.

A single usage report has a practical payoff at the acceptance and payment stage of a lowest-price contract. Because input and output usage is reported per model and per key, it is possible to trace which task type produced which share of monthly cost; large-model usage rising above expectation is an early signal that something is wrong in the flow design. On pricing, an 8% platform margin applies to credit top-ups, while no margin is added to the model prices themselves, which means the published unit prices can be used directly in approximate cost and bid calculations.

Two points on the data side matter for municipal design. First, models hosted in Turkey are available in the catalogue; models such as llmtr/gemma-4, llmtr/qwen3-6-35b and llmtr/embeddinggemma-300m are called through the same interface as global provider models in the same catalogue. For flows where sending citizen text abroad is not preferred, a Turkey-hosted model removes the cross-border transfer assessment from the agenda. Second, user prompts and model response bodies are not written to the usage and billing database, and customer API keys are stored as SHA-256 hashes rather than in plain text.

Nothing in this article implies that LLMTR holds any certification, accreditation or official approval. The platform is an infrastructure component; establishing the approved source set, defining handover thresholds, preparing the privacy notice and drafting specification clauses remain the institution's own responsibility.

Sources

The legislative references and tender information in this article were verified against the primary sources below. Last checked: 13 August 2026.

This content is informational and does not constitute legal advice.

• Law No. 4734 (Kamu İhale Kanunu, Public Procurement Law), Articles 19 and 40 — mevzuat.gov.tr
• Law No. 6698 (KVKK, Personal Data Protection Law), Articles 4, 5, 6, 9, 10 and 12 — mevzuat.gov.tr
• Tender notice for Yapay Zeka Asistan ve Yapay Zeka Müşteri Temsilcisi Yazılımı Kiralama Hizmeti, IKN 2026/743700 — bahcelievler.istanbul
• Esenyurt Municipality announcement on its AI-supported WhatsApp solution line, 3 June 2026 — esenyurt.bel.tr
• Report on Nevşehir Municipality's AI-supported communication system, 12 July 2026 — fibhaber.com

Steps to build a municipal AI solution line

Six steps for building an AI layer for a municipal call center and citizen solution line: demand inventory, approved source set, task-based model assignment, handover rules, KVKK inventory, and a pilot with measurable acceptance criteria.

1. Build the channel and demand inventory. Consolidate the last twelve months of call center, WhatsApp, web form and social media records into a single table. Group requests by subject heading, order them by volume, and mark which department each group goes to. The repetitive headings that account for the bulk of volume define the initial automation scope, while the hour and day distribution of queue pressure justifies out-of-hours coverage.
2. Establish the approved knowledge source set. Restrict the documents from which the model may answer to sources the institution itself has published: the council resolution setting the fee schedule, the service standards table, required-document lists, official announcements and departmental internal circulars. Assign each document an owner, an effective date and a person responsible for updates. Do not admit documents without an identified owner or effective date.
3. Decompose the tasks and assign a model to each. Split the work into separate components for classification and routing, knowledge lookup against approved sources, ticket creation and summarisation. Assign a small model to classification, a medium model to knowledge lookup and summarisation, and a large model to complex requests involving statutory exceptions. Use retrieval-augmented generation only in the knowledge lookup and complex request components, where answers must rest on approved documents.
4. Define handover thresholds and human approval points. Tie human handover to three triggers: classification confidence falling below threshold, no match in the approved source set, and the topic falling into the sensitive-topic list. Exclude subjects such as social assistance, health declarations, legal disputes, staff complaints and burial procedures from automatic answering. Show the citizen a summary for confirmation before creating a request ticket.
5. Update the KVKK inventory and the privacy notice. Record the new channels and processing activities in the personal data processing inventory, and determine the legal basis under Article 5 of Law No. 6698 (KVKK) for each activity. Put the masking rules for fields sent in the prompt into written policy. Provide access to the privacy notice from the first WhatsApp message, the web chat window and the voice channel announcement. Write retention period, access rights and destruction method into the contract.
6. Run a pilot and write the metrics into the specification as acceptance criteria. Run a pilot limited to the two or three highest-volume subject headings and measure first-contact resolution rate, human handover rate, average handling time, satisfaction and routing accuracy broken down by task type and channel. Convert the values observed in the pilot into realistic thresholds and write them into the technical specification as minimum requirements and acceptance criteria. State the reporting breakdown and reporting frequency in the specification as well.

Frequently asked questions

Under which procurement procedure are municipal AI call center projects bought in Turkey?

In one verified example the work was procured under the open tender procedure of Article 19 of Law No. 4734 (Kamu İhale Kanunu, Public Procurement Law). Bahçelievler Municipality's IT Department published tender IKN 2026/743700 for "Yapay Zeka Asistan ve Yapay Zeka Müşteri Temsilcisi Yazılımı Kiralama Hizmeti" with a tender date of 11 May 2026 at 10:00 and a duration of 365 days from the start of work. The notice states that only domestic tenderers may participate and that bids may not be submitted as a consortium. Each administration may select a different procedure according to its own needs and approximate cost.

Who is responsible if a municipal chatbot gives a citizen wrong information?

For personal data processing the municipality is the data controller, and obligations under Law No. 6698 (KVKK) do not change according to whether processing is carried out by staff or by software. Responsibility for the substance of the service depends on the contract and technical specification between the administration and the contractor. For that reason the scope of the approved source set, who is responsible for updating it, the requirement to log which document each answer relied on, and the topics on which automatic answers are prohibited must all be written explicitly into the specification. This content is informational and does not constitute legal advice.

In a lowest-price tender, where do quality requirements belong?

In lowest-price tenders quality and technical merit carry no score at bid evaluation. Article 40 of Law No. 4734 provides that the economically most advantageous tender may be determined on price alone or on price together with non-price factors, and when the administration selects the first route the technical specification becomes the only document carrying quality. Accuracy thresholds, human handover rules, retention periods, reporting breakdowns and the sensitive-topic list must be written into the specification as minimum requirements. A requirement absent from the specification cannot be demanded during the contract period.

Are the personal data in a citizen request sent to the model?

Avoiding that should be a design goal. Article 4 of Law No. 6698 (KVKK) requires personal data to be relevant, limited and proportionate to the purposes for which they are processed, and routing a request to the correct department does not require a name, address or telephone number. In practice, identity and contact details are written to the institutional system holding the request ticket, while they are stripped from the text sent to the model through masking or removal. Requests containing special categories of data such as health status should be removed from the automated flow and passed directly to authorised staff.

Which tasks on a municipal solution line actually need a large model?

The need for a large model concentrates in a small share of volume. Intent classification and routing operate over a bounded label set and can be served by a small model; knowledge lookups such as fee schedules or document lists are resolved with a medium model plus retrieval over an approved document set. Large models should be reserved for complex requests involving statutory exceptions or several departments at once. Assigning models by task lowers cost per request against a single-model architecture.

Which metrics measure the success of a municipal AI solution line?

Four metrics are the minimum: first-contact resolution rate, human handover rate, average handling time and citizen satisfaction. Routing accuracy, measured as the number of inter-department returns, should be added to these. Metrics must be reported broken down by task type and channel rather than in aggregate; otherwise the success rate on high-volume simple questions conceals failure on complex requests. The target for human handover rate is not zero, and a high handover rate on sensitive topics is correct behaviour.

Related posts

• Writing an AI technical specification for public procurement: clause-by-clause examples
• How to build an in-house AI assistant: architecture decisions for public institutions

• Model catalog
• Pricing
• API keys
• KVKK Disclosure Notice