EN TR
Get a quote
View all services
Web software

One app carries the brochure pages and the request queue.

System architecture

The pieces and their boundaries are settled before code.

Enterprise & commercial software

Several institutions, one system, records kept apart.

Mobile app

One codebase, both stores: iOS and Android.

Software consulting

We take a running system over and improve it.

AI consulting

AI only where the problem actually calls for it.

Get a quote
EN TR

CRM · Istanbul

CRM for Istanbul businesses

When the same customer sits in three places, the office sheet, the technician's notebook and a phone call between them, one service record is living in all three at once. That is the first question behind CRM software in the Istanbul market: where does a record open, and where is it written? The work closest to how this market runs is AlgoKlima, our own product rather than a client handover. Its field app does not wait for a connection: a job opens straight into a local queue on the phone.

Get a quote Tell us about your project

CRM — Istanbul

Boiler rooms, lift shafts and underground car parks are where coverage ends, and service calls go into them. A second visit costs travel and time, so a half-filled record costs more than data. AlgoKlima is built around that: a job opened out of coverage waits in the phone's local queue, and when the connection returns the queue drains in the order entries were created — van and desk edits resolve into a single record. Warranty and maintenance history hangs off the unit, not the contact card. The office panel runs on Laravel with Inertia, the field app on React Native (Expo); both read from one MySQL database. Two interfaces, one application underneath.

  • A job opened with no signal goes into the phone's local queue; it drains in creation order, and site and desk edits resolve into one record.
  • Warranty, maintenance and fault files sit under the unit, not the person, so a device carries its history when it changes hands.
  • The plan is its own record, a booking attaches to a step of it, and the package balance sits on the customer record.

Why Algoriel

  • Booking, plan and invoice kept apart

    The dental CRM holds a treatment plan per tooth; an appointment attaches to a plan step, so moving the plan moves the calendar.

  • Request types split up front

    At Diotek a site survey and a service call are two separate flows and never share a form.

  • No second document

    Tahlil.com takes the values in and writes the specialist's reading onto the same record, so the result stays in one place.

  • History belongs to the equipment

    AlgoKlima keeps service history under the unit rather than the customer, so it travels with the unit when it changes hands.

What we build

CRM

  • A service plan that moves step by step

    A treatment or maintenance programme that runs over several sessions is kept as its own plan, separate from the bookings. In the dental clinic CRM the plan is built tooth by tooth and split into sessions spread over weeks.

  • Appointments tied to the plan

    Each appointment is attached to a step in the plan. When the plan changes or a session is added in between, the calendar updates with it.

  • Package and membership balances

    When you sell classes or services in packages, what a customer has left shows on their card. At Pilatesco a booking takes one class off the package, and cancellations and no-shows follow different rules.

  • Service history per device

    Warranty, maintenance and fault history for the equipment you service is kept against the device, not the person. At AlgoKlima three air conditioners at the same address keep three separate files.

  • History that survives a change of owner

    When a device passes to someone else, its history stays with the device instead of being retyped onto the new customer's card.

  • The work done and the invoice in one place

    The procedure sits on the customer's record, so what was billed and what was carried out are read from the same place and nothing is entered twice.

Work like this

CRM · Case study

AlgoKlima service management — our own product, field records that open with no signal

Our own product for air conditioning, boiler and appliance service teams — a system whose upkeep we live with, not a client handover. The office panel runs on Laravel with Inertia, the field app on React Native (Expo), both reading from one MySQL database with Redis carrying the read load. A technician opens and closes a job with no signal: the record waits in the phone's local queue and drains in the order entries were created, so field and desk edits resolve into one. Warranty and service history stays under the device.

Read the case study →

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

  • Do you have an office in Istanbul? Will someone come to us?

    We keep no office and work fully remotely. The order matters more: we map the field and office flows together, decide which information belongs in which record, and build after that.

  • A technician is in a basement with no signal. What happens to the record?

    It opens and waits in the phone's local queue; neither starting nor closing a job needs a connection. When the signal returns the queue drains in the order entries were created, and a desk edit on the same record resolves against it.

  • Would an off-the-shelf CRM be enough for us?

    If a contact list and a calendar cover the work, then yes, and we say so rather than sell a build. The line falls where a plan's step, a package balance, or a device's service history has to live in the record itself.

  • Bookings and fault calls land in the same form and the queue gets tangled.

    They do not belong in one record. In the CRM we wrote for a dental clinic a booking attaches to a step of the treatment plan, while in AlgoKlima a fault call opens against the device's own record. Even when both arrive through the same form, the two records keep their own shape.

CRM in other cities

The other cities where we publish this service are below, grouped by province.

Other services for this location

Want to bring your customer tracking into one system?

Get a quote or open the service