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 · Kadikoy

CRM for Kadikoy businesses

Kadikoy trades through small operators: clinics, studios, cafes and single-branch retail. If your bookings run through one diary that a single person keeps, that diary answers when. It does not answer where a customer stands inside a commitment that runs across several visits. The work closest to how this district operates is a CRM we built for a dental clinic, and it turns on one distinction: the plan and the calendar are separate records, and the order of the work lives on the plan.

Get a quote Tell us about your project

CRM — Kadikoy

In Kadikoy's appointment-led trade the question is where the sequence lives. The plan is drawn tooth by tooth. Each procedure is assigned to a tooth, and the set is broken into ordered sessions spread across weeks, so sequence belongs to the plan rather than the diary. An appointment is not an open hour; it carries the session it answers to. That is what lets the calendar move on its own: reorder a step, or drop a new session into the middle of a course, and the bookings after it shift with the plan. Billing follows the same rule. The procedure is already recorded against the patient, so what was charged and what was carried out are read from one place, and month-end is another view of that record, not a fresh set of figures typed elsewhere. Laravel runs the workflow; MySQL holds patients, plans and invoices.

  • Treatment is planned per tooth and split into ordered sessions, and the plan stands on its own before anything is booked.
  • A booking names the session it belongs to, so reordering or inserting a step moves the calendar with the plan and leaves no orphaned slots.
  • Invoices are read off the patient record, not a separate book, and reporting is a second view of the same 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

A dental clinic CRM — treatment planned per tooth, bookings tied to a session

The clinic had been running multi-visit treatment on a general booking tool. It recorded the hour and never the step. Progress had to be inferred from the diary, charges sat in a separate ledger, and the month-end picture was assembled by hand from both. What we built puts the sequence in one place: treatment is planned per tooth and broken into ordered sessions, every booking names the session it answers to, and invoices and reports are read off the patient record. Laravel and MySQL carry it; the clinic did not get a stack of its own.

Read the case study →

Working with Kadikoy 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 Kadikoy, or someone who can come to the practice?

    There is no office to visit and nobody who drives out to you; we work entirely remotely. The first deliverable is written, not built: plan, booking, invoice, and which record owns which fact.

  • Would an off-the-shelf booking system do the job?

    If a diary and a contact list cover what you sell, they do, and we say that rather than quote a build. The line sits where a booking has to know which step of a multi-session plan it belongs to.

  • The plan changes halfway through — what happens to booked appointments?

    They move with it. Each booking names its session, so reordering or inserting a step shifts everything downstream. No slot is left pointing at a dropped session.

  • Is this only useful to dental practices?

    The mechanism belongs to multi-session commitments, not to dentistry. While the sequence is held on a plan, the calendar reads from it whatever the work is called. For booking flows that vary by sector we are building AlgoRandevu ourselves right now, and it is still in development.

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