Get a quote

Process Tracking · Esenyurt

Process Tracking for Esenyurt businesses

When the result of a step lives inside a machine, the process waits for that machine to be free. If a course branch along the Kirac stretch in Esenyurt and another branch run the same mock exam in the same week, the sheets have to travel to wherever the single reader sits. Process tracking software for Esenyurt starts at that queue. In the tool we wrote for Vipkurum, a mark is read from the picture of the sheet rather than through a device's optics, so the branch reads its own exam.

Process Tracking — Esenyurt

Esenyurt's texture is dense small business and private education, where one name can sit across several branches. A process can only be tracked once its input becomes a record, and when that input is a printed sheet the chain breaks at the very first link. The work closest to this district's sector profile is Vipkurum's optical reading tool, written for education technology. Where it does not overlap: a quality sheet on a production line, a payroll timesheet or a field roster are outside what we have built. We describe one step — how a mark on paper becomes a record. Python and OpenCV do the reading, the service is called through Node.js, and the result lands on a MySQL record. We keep no office; the work runs remotely.

  • Marks are extracted from the picture of the sheet, so the reading sits in an OpenCV layer rather than in a device's optics and no reader hardware has to be free first.
  • A new sheet layout is absorbed on the Python side, which leaves no hardware swap and no device-specific sheet supply anywhere in the chain.
  • A branch reads its own mock exam: the sheet is uploaded from a browser and the result lands on the same exam record, so no paper travels to a central address.

Why Algoriel

  • Keeps working offline

    The field app keeps recording with no connection, and the queue reaches the server in order once signal returns. That is how AlgoKlima runs.

  • Entry from QR and location

    Where no fixed terminal can be installed, entry and exit are logged from a QR code and a location reading, and entitlement is worked out from those readings.

  • Records land the same hour

    Jobs close in the field, so the office sees where each one stands without waiting for end of day.

  • Office and field read one source

    The office panel and the field app read the same information, so nobody keeps a spreadsheet alongside it.

  • What the record attaches to

    Rather than mapping a process in the abstract, we decide what a record hangs on. On the construction system a row belongs to a person and a site at once, and the two are never separated. In AlgoRandevu we are building a structure where a booking can attach to a person, a room or a piece of equipment.

  • The entry that stays open

    Instead of a live dashboard, one rule: a matched check-in and check-out produce the hours, and a check-in with no scan out stays open. Whatever is stuck shows up as that gap.

  • Who was where, on the record

    Because a single row carries both the person and the site, totals separate by site. When one worker spends the month across two sites, those hours never fall into the same bucket.

  • What is left when the figure is disputed

    Because payroll is derived from matched pairs, the number argued over at month end has a time- and location-stamped record behind it. There is no parallel calculation sheet to reconcile against; the dispute happens over the record itself.

  • Records taken beyond coverage

    In AlgoKlima's service flow the chain does not break where the network does. Once the connection returns the waiting entries are processed in the order they were created, and an edit made in the field and one made in the office merge into a single record through conflict resolution.

  • Process rules kept out of the code

    Rules like the length of a step and the gap between consecutive ones belong in a product setting, not in the code. The aim is that changing one does not mean shipping a release, and that is what we are building into AlgoRandevu right now.

Work like this

Process Tracking · Case study

Vipkurum optical reading — the mark comes off the picture, not off a reader

The reading tool we wrote for Vipkurum's education platform. Marks on an optical sheet are extracted from the image of that sheet rather than through a device's optics: the work sits in an image analysis layer standing on Python and OpenCV, not in hardware. Marking no longer waits for a reader to be free, and a branch reads its own exam without sending paper away. When a layout changes the adjustment happens in software: no hardware swap, no device-specific sheet order. Sheets upload from a browser, the reading service is called through Node.js, and the result lands on a MySQL record. Scope: exam marking, not document recognition.

Read the case study →

Working with Esenyurt teams, remotely

We have no office, so work for this city runs remotely and we do not offer on-site support. What was done, and why it was done that way, stays in writing. The project pages mark which builds came out of a partnership.

  • The first release ships as a working piece; extras follow later.
  • Every client we know of is in Turkey.
  • Decisions stay in writing; progress shows in working screens.

Frequently asked

  • Our paper is not an exam sheet but an inspection checklist. What does this tool say to us?

    It was written for exam marking and we say that plainly. It is not a general document recognition product, and we have no inspection or production form work to show. What carries across is narrower: reading can sit in a software layer working on the picture of a sheet instead of inside a device.

  • Our branches are at separate addresses. Can each one read its own mock exam?

    It can. The sheet is uploaded from a browser, the reading happens on the service side, and the result is written to the same exam record. The step where paper has to reach the address holding the reader disappears.

  • Our sheet layout changes every term. Does that mean buying a new device?

    No. Adapting to a new layout happens on the Python side. Nothing in this chain depends on a hardware swap or on ordering sheets made for a particular device, so the adjustment stays in software.

  • What if a mark is read wrong? Do you publish an accuracy rate?

    We publish no rate, because we have measured none. A sheet falling outside the layout does not close as if it had been read: the record stays incomplete rather than being filled by eye, and a person decides what happens next.

What stands behind your month-end figure today?