Get a quote

CRM · Sariyer

CRM for Sariyer businesses

A customer who works on the office floors along Büyükdere Caddesi postpones a Tuesday. In a diary that is an hour deleted, and nothing left behind says where the commitment now stands. In Sariyer the CRM question is less about drawing a plan than about where a postponement is written. In the CRM we built for a dental clinic a booking is not an open hour but a named step of a plan, so moving the date moves that step's place in the calendar and carries the bookings after it, leaving no slot that answers to nothing.

CRM — Sariyer

Office floors in Sariyer sit alongside the service businesses at Tarabya and Kireçburnu. When a client's day is rearranged by somebody else's meeting, postponement stops being the exception. The work closest to this district's operating profile is a CRM built for a dental clinic. Where it does not overlap should be stated: a technology office's own release and issue tracking, or the flow of a finance product, is not work we can show, and we claim nothing there. What carries across is where a postponement is written. A booking names the step it answers to, so changing a date does not break the commitment; only the order shifts. Underneath it is one application: Laravel runs the work, MySQL holds the plan and booking records.

  • Postponing is not deleting an hour: the booking names its step, so the step stays on the plan and only its date changes.
  • Dropping a session into the middle of a course moves everything after it on its own, so nobody re-sorts the calendar by hand.
  • Where a person stands in a commitment is read off the plan rather than guessed from the diary, because the plan holds the sequence itself.

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 — a booking names its step, so postponing shifts the order

In this build a booking is not an open hour; it is the counterpart of one step in a treatment plan. When a patient postpones, the step does not drop off the plan: its place in the calendar changes and the bookings after it move down in sequence. Inserting a new session mid-course behaves the same way, so nobody re-sorts the diary by hand. The clinic manager reads where a patient stands from a single screen instead of inferring it from the calendar. Laravel runs the process and MySQL holds the plan and booking records. The scope is bounded by how this clinic works: another sector's flow is not something we can point to here.

Read the case study →

Working with Sariyer 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 clients postpone constantly. How does the system take that?

    Postponing deletes nothing. The booking names the step it answers to, so only the date moves while the step stays on the plan, and the bookings after it shift in sequence. No hour is left in the calendar answering to nothing.

  • Our customers are corporate office teams. What does a dental clinic example tell us?

    The mechanism belongs to commitments that run across several meetings, not to dentistry. While the sequence stays on the plan, the calendar feeds from it. The limit is worth saying too: a technology office's own build process is not something we can show.

  • Do you have an office in Sariyer, or a team that comes out?

    Neither exists; we work fully remotely. The first deliverable is written: what the steps of a plan are built from, and which record moves when a postponement arrives. Development starts after that.

  • If a session is cancelled outright, does the plan close?

    It does not. The plan is a record that stands on its own, independent of any booking, so a cancelled step stays on it without a date. What says the commitment is unfinished is the plan itself, not the calendar.

Want to bring your customer tracking into one system?