Get a quote

Process Tracking · Pendik

Process Tracking for Pendik businesses

Planned maintenance comes off a calendar. A breakdown call comes off a phone. Both take parts from the same shelf, and by mid-afternoon that part has usually come out of the back of a service van. If you run a multi-site operation around Kurtkoy and Seyhli in Pendik, tracking breaks right there: one answer says where the job stands, another says where the part went. AlgoCar keeps both answers on a single record — our own product, whose upkeep we carry.

Process Tracking — Pendik

Pendik's texture puts Anatolian-side manufacturing SMEs and multi-site service organisations side by side. If you commission as well as repair, the machine installed in spring returns as a fault record in autumn. The work closest to this district's sector profile is AlgoCar. Where it does not overlap, plainly: the unit AlgoCar follows is a work order, not a person. Shift hours, timesheets and attendance sit outside that scope, so process tracking software here is not clock tracking. Treating the parts a van carries as a store of its own was never built either. One technical foundation underneath: Laravel runs the job, MySQL holds the records, Redis takes the read load, Inertia carries the panel, React Native (Expo) sits on the technician's phone. Nobody travels out for setup; the team works remotely.

  • Planned maintenance and a breakdown call open as separate work types, so one queue never hides the other and each moves through on its own terms.
  • A part is written to the work order it was used on, which is how two work types can look at one shelf without the shelf splitting in two.
  • Where a job stands and what it has consumed come off the same record, so the office list and the workshop floor are not set against each other at the end of the day.

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

AlgoCar — two work types, one parts store, one record per job

Our own service system, built around the vehicle that comes into the workshop; not a client handover but something whose upkeep we carry. Planned maintenance and breakdown calls are separate work types: one opens on a calendar, the other on a phone. Both look at a single parts store, because consumption is written to the job's own record and the shelf never splits into two lists. What a job has reached and what it has taken sit next to each other. AlgoCar was written for a vehicle workshop; what carries across is not the screen layout but the link between a work type and a parts record.

Read the case study →

Working with Pendik 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

  • We keep planned maintenance and breakdown calls in one list. What does splitting them change?

    One list puts them in order and forgets what they are. Planned maintenance has a date agreed in advance; a breakdown call exists because someone rang. Sitting in the same column, neither shows which one has slipped. As separate types each keeps its own queue, while on the parts side both still look at one shelf.

  • Most parts leave from the back of the service van. How does that get recorded?

    We did not build the van as a store of its own, and we say so up front. In AlgoCar consumption is written to the work order the part was used on, so a movement has one place of birth. If you want the van counted as a separate warehouse, that is not something we can show.

  • Our service points spread beyond Pendik. How does the centre see where a job is?

    A record is created at the point where the job opened, but it does not sit in a copy of its own — everything writes to the same core. Someone at the centre reads the queue by work type and status rather than point by point, and no service point needs a program of its own.

  • Once a job is closed, can we still see which parts went into it?

    You can, because consumption was written to the job rather than to a separate stock ledger. Open a closed work order and the parts used on it are listed there. There is no second source to reconcile against; that record is the source.

What stands behind your month-end figure today?