The pieces and their boundaries are settled before code.
Several institutions, one system, records kept apart.
One codebase, both stores: iOS and Android.
We take a running system over and improve it.
AI only where the problem actually calls for it.
Process tracking
Business process tracking software turns a matched pair of scans into the hours. A check-in with no check-out to answer it stays open on the list. Records are still taken where there is no signal, and the queue clears in order once the connection returns.
Process tracking means reading a recurring job from its own record rather than a spreadsheet beside it. Jobs like a worker checking in and out of a site, or a service call opened and closed in the field, qualify; the first decision is what the record attaches to. At the construction site attendance system one row carries the person and the site together, and the hours come from a matched pair of scans.
At every month end the argument starts in the same place: who worked on which site, and for how long. If the answer lives on a paper timesheet, it really lives in the memory of whoever filled it in. When someone disputes it there is nothing underneath, and the discussion turns to the person who wrote the number rather than the number.
The construction site attendance system rebuilt that chain from the start. Arrival and departure are logged by a code scanned from the worker’s own phone. Nobody types an hour into a form, the approach we lay out in logging entry and exit without a turnstile. The hours come from those two rows finding each other. A check-in whose exit was never scanned does not close; it sits open and stands out on the month-end list.
Payroll is the sum of those pairs. One worker’s records on different sites are totalled separately, so on a site where several subcontractors work at once, who was booked to which job is not a puzzle to untangle afterwards.
The second case is field service. In AlgoKlima the chain does not break where the network stops: a record made in the field is processed in the order it entered the queue once the connection returns. If the office touched the same record, the two edits merge through conflict resolution and no second version survives. The office reads the record itself, not a summary retyped in the evening.
The next step is what we are building in AlgoRandevu: a product where rules such as the length of a step and the gap between consecutive ones are written as settings rather than code. The aim is plain: changing a rule should not require a release. AlgoKlima and AlgoRandevu are our own products, so we do not describe the maintenance cost of process software to a client. We carry it ourselves.
This page sits under enterprise software and answers one narrow question: where the closing of a recurring job gets written. A company’s internal rules, its capacity and who may see what belong to the management systems page, and the history of the relationship with a customer to the CRM page.
Every item below is drawn from two systems already running in the field:
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.
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.
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.
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.
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.
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.
Every project goes through the same four stages: planning, architecture, modelling, development.
See our process
A construction site is temporary, so no turnstile goes up and crews move between projects. Entry and exit are logged from the worker's own phone with a QR scan and a location check. At month end, who was where and for how long is read back out of those records.
Our own product for HVAC, boiler and appliance service companies. The customer and device records the office works from are the same ones the technician carries into the field. A job can be opened and closed in a basement with no signal, and service history stays tied to the device.
Our own product, still in development and not yet live. How long an appointment runs, what it is booked against and how bookings stack all differ by trade, so we are keeping those rules configurable inside the product instead of fixing them in code.
The request names a screen, but the list of questions is what is missing. Read the three lines that belong under an indicator, and the third one that never appears on screen.
Ask what a workflow is and you get a drawing back. What tells you where a job is waiting is the record: the state it sits in, and the party allowed to move it on.
If the fingerprint reader is questioned, which field of a timekeeping record is tied to a body? The identity field takes a reissuable identifier; the record model stays. A lawyer answers the rest.
Silence gets read as satisfaction. In fact the question leaves the customer, reaches an address and is answered there. Four fault patterns name where it goes and who answers it.
A field app earns its keep where the signal dies: where data is first written, how the phone's queue empties in order and how conflicts merge, drawn from our service-management work.
Hand a spreadsheet to a software team and only part of it can travel: some columns are typed data, some are formula results, and some have no counterpart in the old tool at all. Which is which?
The software ticks every line on your list and the work still does not fit. How to bring the two things a developer asks about, the conditions of the work and the record, to the first meeting.
A turnstile never gets installed on a site that will be dismantled. When identity and location live inside the record itself, matched entry-exit pairs yield hours worked, and pay follows from them.
A demo runs from the vendor's side. The difficulty your system was built for begins when the other side touches the same record; take the scenario from there and sign on the record's state.
Recurring ones with a step, an owner and a closing record. Two real examples: a worker checking in and out of a construction site, and a service call being opened and closed in the field. If your flow never writes its closing down anywhere, it cannot be tracked and it cannot be measured either, so the first job is deciding where that closing gets written.
A matched pair of records. Arrival and departure are scanned from your worker's own phone, the hours come from that pair, and payroll is the sum of those hours. We do not install another box where the turnstile stood, because what the month-end figure rests on is the record rather than a device. The construction site attendance system logs arrival and departure with a QR scan and a location check.
It can, but we will not tell you integration is standard. Before connecting anything we settle two questions with you: where information is first entered, and which side wins when both systems edit the same one. Systems joined without those two answers produce two numbers that disagree at month end.
The number of processes matters less than where your information is first entered. If it starts in the office the work is shorter; if it starts in the field with no connection, the sync behaviour has to be defined up front. We settle the scope with you before anything is built, and we answer that question before giving you a number of days.