Gains:
- It digitizes a public application process step by step and determines where the human being is kept at the decision point.
- By anticipating the digital divide and inequality of access, it leaves an alternative channel for every process.
- Designs exception and error management; When the model is unsure, it makes it a rule to direct it to the human instead of rejecting it.
A growing part of the citizen's contact with the public takes place online: obtaining documents, applying, appointments, payments, status inquiries via the e-Government Gateway. E-government (delivery of public services through digital channels, from a single point and often without human intermediaries) both facilitates the work of citizens and reduces the burden of the institution. Behind these digital services are workflows and, increasingly, process automation (automatic execution of repetitive steps such as receiving applications, routing, checking missing documents, sending notifications with software). AI is a powerful tool in designing these flows, producing forms and notification texts, pre-evaluating incoming applications and finding blockages in the process. But with a caveat: every rights-creating/limiting decision made by an automated process must be legally tied to a point that a human can review and justify. Fully automated rejection is illegitimate without objection and human review.
In automation, "where are people kept?" question
The most critical decision when designing process automation is at what point the human will be involved. There are three common models:
- Full automation (no humans): Suitable only for non-entitled, low-risk, rule-clear tasks — for example, automatic generation and delivery of a document from the system. It may be preferred if the rules are completely clear and the error is low cost.
- Human-in-the-loop: AI/system produces a suggestion, the human approves or corrects it. This is the standard model of rights-creating/restricting decisions. For example, the system pre-evaluates an application for assistance and the officer makes a decision.
- Under human supervision (human-on-the-loop): The system operates automatically, but humans monitor, sample, check, and receive exceptions. It is used in high volume, medium risk jobs.
Key principle: the more the decision affects the rights of the citizen, the more the person should be at the center. The automatic assignment of an appointment time and the automatic decision to close a business cannot be subject to the same regime.
Hint: For each automatic step, "if this step works wrong, how can a citizen object and how can a human fix it?" Redesign the answer to the question from scratch. Automation without any means of objection is both legally and ethically flawed.
Step by step: designing a digital process
- Map the process. All steps, decisions and actors from application to conclusion.
- Classify by risk. Does each step create/restrict rights? Where is man necessary?
- Select what to automate. Rule-clear, low risk, repetitive steps.
- Generate form and notification texts. Simple, accessible, personal data-minimal.
- Establish objection and exception paths. Attach a human checkpoint to every automated decision.
- Control personal data flow. Which data goes where and for how long? (KVKK)
- Pilot, monitor, improve. Measure error rate and complaints; fix it.
three mini cases
Case 1 — Incomplete document automation. In one institution, 38% of applications were rejected due to missing documents, and citizens were coming again. When an AI-supported missing document check was added at the time of application, the citizen saw the missing document before even submitting the form; The second application rate decreased from 38% to 11%, and the box office burden decreased.
Case 2 — Fully automatic rejection reversal. A social aid pilot automatically calculated the income threshold and automatically rejected those above the threshold. But some special situations (disabled care burden, temporary income) were not included in the rule and there were unfair rejections. The process has been converted to a “human in the loop” model: the system pre-evaluates, the officer sees the exceptions and makes the decision. Complaints of unfair rejection disappeared.
Case 3 — Clogging detection. A unit that analyzed 6-month process logs with AI found that an average of 9 days of applications were waiting for a single approval step; There was only one authority at that step. When the authority was given to a second person, the average time decreased from 14 days to 6 days.
Four copyable templates
1) Process map and risk classification:
Your role: public process designer. Extract all the steps of the service below, from application to conclusion. For each step, specify: (1) what is being done, (2) does it create/restrict rights, (3) will it be automated or will human judgment be required, (4) is the main risk here. Mark the legal point you are unsure of as "must be confirmed". SERVICE: [describe]
2) Plain notification/form text:
Write a notification text to the citizen for the following situation: simple, respectful, step by step. Clearly state what needs to be done, the duration [to be confirmed] and the way to object. Do not request unnecessary personal data. Don't use jargon.SITUATION: [e.g. missing document / application result]
3) Objection and exception route design:
Design a human control and objection mechanism for the following automatic decision step: (1) how the citizen objects, (2) which cases should go out of the automatic and go to the human (exceptions), (3) what the human should look for when making the decision, (4) time and record. Avoid fully automatic rejection.STEP: [automatic decision]
4) Process bottleneck analysis:
Examine the process logs (step - duration) below. Just given the data: (1) longest waiting step, (2) possible bottleneck cause (single authority, manual operation, etc.), (3) give 2-3 improvement suggestions. Adding numbers from outside.LOG: [step and time data]
Weak prompt / Strong prompt
Weak: “Automate this application process.”
Güçlü: "Public process designer of the role. First extract all the steps from application to conclusion and classify each step as 'right-generating/non-righting', 'automated/human-required', 'main risk'. Only recommend rule-clear and low-risk steps to automation; design human approval and objection path for each right-limiting step, do not recommend fully automatic rejection. Mark the personal data flow (which data goes where). Separate ambiguous legal points as 'must be confirmed'."
The difference: powerful prompt separates automation by risk, enforces human review and appeal, makes data flow and legal uncertainty visible.
Automation model selection
business type
Suitable model
Why
Document production (rules-net)
Full automation
Low risk does not create rights
Aid/incentive evaluation
human in the loop
It creates a right, there are exceptions
High volume sorting
under human supervision
Sampling control is sufficient
Penalty/restriction decision
People are at the center
Severe restriction of rights, justification required
Access parity and exception management
While digitizing and automating a public process increases efficiency, it creates a new risk of inequality: the digital divide (the inability to access services for citizens without computers, internet access or digital literacy). Elderly, disabled, rural or low-income citizens may be excluded from an entirely online process. A well-designed digital process always leaves an alternative channel (face-to-face application, telephone support, proxy transaction); Automation does not confine the citizen to the channel, it offers him options. Likewise, good automation is designed around exception handling (what happens when a missing document, system error, exception occurs), not an "all goes well" scenario; Because the real victimization in the public sector is experienced by the citizens who fall outside the rules.
Mini case — those excluded by automation. When a welfare application moved entirely online, the number of applications dropped 30 percent in the first month — not because demand had decreased, but because the neediest groups, senior citizens and citizens without internet, could not apply. When the institution opened supported application points in headmen's offices, the number recovered; efficiency balanced with equity of access.
Mini case — process stalled in exception. In an automated licensing process, the document was pre-checked by AI; but the system silently rejected applications, deeming a rare type of document as "invalid". About 15 legitimate applications per week fell into this blind spot. The solution: when the model is unsure, refer it to the officer rather than rejecting it.
Template that controls process design:
Task: Produce a RISK and ACCESS checklist for the following digital process.Process: [step by step flow]Questions: 1) How does a citizen without internet/device apply? 2) Is disabled access provided? 3) What happens to the application if the system gives an error? 4) Who decides in case of exception/rule? 5) If automatic rejection is given, is there an objection method and human control? Output: Risk level + recommendation for each question. Adding a fitting solution.
Tip: Evaluate an automation not by “how many processes did it speed up” but also by “who did it leave out?” Success in public service is measured by the minority that is not left out as much as the majority that steps up.
Common mistakes
- Making the right-limiting decision fully automatic. It is illegitimate without objection and human control.
- Trying to fit exceptions into the rule. Real life goes beyond the rule; Leave human door for exception.
- Thinking about the way to object later. Design a way to challenge and correct every automated decision from the beginning.
- Not controlling the flow of personal data. Automation replicates data; Check where it goes and the storage time.
- Writing the notice in jargon. If citizens do not understand, the process will be digital but inaccessible.
- To expand without pilots. Measure the error rate on a small scale first, then expand.
In summary
E-government and process automation speed up public service and reduce the burden; AI is powerful at mapping these processes, generating text, pre-evaluating and finding bottlenecks. But the heart of design is one question: where is the human? The more the decision affects the rights of the citizen, the more people should be at the center; Every automatic decision should be connected to an objection and human control point, and personal data flow should be audited in accordance with KVKK.
Application task
Select an online service for your unit. With the “Process map and risk classification” template, extract the steps and mark each one for risk and automatability. Design a human control mechanism for a rights-generating step with the "Objection and exception path design" template. Generate a notification text with the "Simple notification/form text" template and check its accessibility.
checklist
- [ ] I have classified each step in terms of risk and automatizability.
- [ ] I have not left any rights-restricting decisions to full automation.
- [ ] I have connected human review and appeal to every automated decision.
- [ ] I designed a human door for exceptions.
- [ ] I have audited the personal data flow and storage period (KVKK).
- [ ] I wrote the notifications simply and accessible; I tested it with the pilot.