Requests, field work and evidence across some 19,000 stops
For İETT, Istanbul's municipal bus and Metrobus operator, we delivered a web and mobile solution that connects reported requests with work in the field, approvals and reporting. Awarded and completed through a public tender.
The customer
İETT is Istanbul's municipal bus and Metrobus operator and part of Istanbul Metropolitan Municipality. Its network covers some 19,000 stops. Cleaning, maintenance, renaming, relocation and the installation of shelters are all part of daily operations — and each follows its own route through the organisation.
The task
Keeping a bus stop in service means more than repairing a shelter or sending a cleaning team. Someone has to record the issue, decide who is responsible, assign the work, collect evidence from the field, review the result and keep the necessary records.
İETT already had tools for managing requests. The task was to connect the work around those requests — the people in the office and the teams at the stops. Four questions describe the need better than any feature list:
- Who is responsible for this request?
- What work has already happened at the stop?
- What evidence or decision is still missing?
- What happens next?
On top of that comes the split in responsibility: some of the work sits with İETT teams, some requires a handover to external organisations.
One shared process for office and field
Office teams organise and review the work on the web. Field teams receive assignments on mobile devices and record results there. Both work with connected stop records.
- 1Module menu: requests, tasks, working files, administration
- 2Every column can be filtered — type, work, source, priority
- 3Unit responsible for the request
- 4Stage and approval status
The interface is in Turkish — the language of the people using it at the customer. DAG-Flow itself appears in German, Turkish or English.
A request becomes an assignment
A reported issue can be followed through to the work needed to resolve it.
A workspace for the office
Coordinators assign work, review it and follow it through its stages.
A mobile application for the field
Staff record observations and task results while on site.
Work tied to the stop's location
Teams find the stop concerned and select locations on the map.
Photographs and structured forms
Reviewers have the supporting information they need to assess the work.
Capture without a connection
Supported work can be saved offline and submitted later.
Reports from recorded data
Collected information is reused in the documents the organisation needs.
Handovers to external parties
Selected work can be passed to contractors or other responsible units.
On the task list (image on the left)
- 1Priority and time
- 2Stop code and location
- 3Distance to the site
- 4Where the request came from
Fewer wasted trips, fewer phone calls
A noticeable share of field work goes into travel and follow-up questions. Several features address exactly that.
Distance to the next task
The task list shows how far the site is, so a round can be ordered by it.
Route guidance
Straight from the task into navigation, without typing an address.
Nearby stops
The device suggests stops in the area — five within 500 metres, for example.
QR code at the stop
The code on the post identifies the stop exactly. No more mistyped codes.
Assignment from the map
Mark an area and assign the stops inside it together.
Assignment by team
Tasks are distributed by team number so the load stays even.
Duplicate reports caught
Repeat reports about the same spot surface before they become two separate jobs.
Messages on the record
Questions between office and field stay in the application, not in private chat groups.
From report to record
The following flow shows how the roles fit together. It does not represent a single documented case; approval stages depend on the type of work.
Record the request
Office or field staff create a request and link it to the stop.
Assign the work
The responsible unit creates an assignment for the appropriate team.
Record the result
The field team adds the required details and photographs in the mobile app.
Review and keep
Review follows the applicable approval route; request, assignment and evidence stay linked.
From proposal to installed shelter
A shelter does not appear because someone requested it. Inspection and a suitability decision come before installation. The solution connects those stages with project quantities, candidate lists and approved installation lists.
- Define the project — name, planned types and quantities, changes in scope
- Assess candidates — inspect locations in the field, record observations
- Decide on suitability — review and approval route; a request does not automatically become an installation
- Plan installations — organise candidate, installation and final lists
- Assign execution — İETT teams or contractors, with quantities tracked
The process diagrams show conditional approvals and document handovers. They do not establish automated integration with the authorities involved.
How this project relates to DAG-Flow
The İETT project is a customer project that helped lay the foundation for the development of DAG-Flow. It is where we learned, in a real operation, how office coordination, mobile field work, evidence and review belong together — and that experience is what sits inside DAG-Flow today.
This is not an installation of DAG-Flow. The solution delivered to İETT is built around the stop operations of a transit authority. A company adopting DAG-Flow today receives a separate product for commercial cleaning, security services and staffing providers.
Where these figures come from
Scope and use: Network coverage, the number of commissioned field users and active use in October 2026 are confirmed by the project owner. The user figure reflects the scope of the contract, not a measurement of active sign-ins.
20+ request scenarios describes the range of reporting routes and responsibilities, not a count of distinct types of work.
Screenshots: The interfaces shown come from the delivered system and contain real operational data. One user name and one case number were removed before publication.
Award: The project was awarded and completed through a public tender; the award result was published. Acceptance: date to follow.
Not measured: No figures are available on time saved, cost reduction or changes in service quality. We make such claims only once they are documented.
A similar situation in your organisation?
If requests, field work and evidence sit in different places today, we are glad to talk about scope, process and what we learned along the way.
- info@dagtech.de
- Phone
- +49 160 225 4395