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

CRM for Kartal businesses

When one management team runs several units, the record splits three ways: people in one program, payments in the accounts package, the timetable on a board. Whoever merges the three at month end is holding the oldest copy of each. That merge is the work a CRM has to take away, on the Uğur Mumcu and Atalar stretch of Kartal as anywhere else. Vipkurum removes it: timetable, assessment, person, guardian, payment and reporting sit on one platform, and every role reaches the same record only as far as its permission goes.

Get a quote Tell us about your project

CRM — Kartal

Kartal holds manufacturing along the E-5 and service floors around the health campus. Where one management runs several units or trade names, each one gets its own front door. The work closest to that arrangement is Vipkurum, written for education institutions. Where it does not overlap: a manufacturer's production record, a bench schedule or a supply flow is not something we have built, and we promise nothing there. What carries across is how permission attaches to a record — a unit enters at its own address, its records stay inside that boundary, and a manager's report comes off that unit's own data. Laravel runs it; MySQL and MongoDB hold the records, Redis carries the cache, React builds the panel and React Native (Expo) the phone side.

  • Timetable, assessment, person, guardian, payment and report share one data model, and a teacher, a guardian and a manager each reach that record only as far as their role allows.
  • An institution defines its own assessment type, so changing a criterion is a definition it owns rather than a code change it waits for.
  • Adding a unit does not mean a fresh installation: the unit is defined once, and its records never open onto a neighbour's screen.

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

Vipkurum — timetable, payment and reporting on one platform, access bounded by role

Seven education institutions run the same system, each under its own domain and brand. Timetable, class, section, exam and payment records share one data model, and a teacher, a guardian and a manager each reach that record to the extent their role allows. A content management layer lets an institution build its own lessons, tests and exams, and because the institution defines the assessment type itself, European and Turkish criteria sit on one infrastructure. Invoices, payments and analytics come off that institution's own data. React builds the panels and React Native (Expo) the phone side, on one Laravel application.

Read the case study →

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

  • Each of our units trades under its own name. Does one system flatten that?

    It does not. Entry happens at the unit's own address, and student, guardian and payment records stay inside that boundary instead of pooling into a shared list. That is how seven institutions share one Vipkurum installation without reading each other's records.

  • We are not an education business. What does Vipkurum say to us?

    Vipkurum was written for education institutions and we say that plainly. What travels is not the curriculum but the arrangement: one data model, several units, and access that narrows by role. A production record or a supply flow is outside what we can show.

  • Do you install anything on site in Kartal?

    Nothing gets installed and nobody travels; we work fully remotely. The first deliverable is written down: which unit owns which record, and how far each role reaches into it.

  • Can management still see one picture across the units?

    A manager's invoices, payments and analytics come off their own institution's data, so no figure has to be retyped into a second sheet to produce that picture. What a manager cannot do is read a neighbouring institution's records; the boundary holds both ways.

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