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

CRM for Pendik businesses

Two different questions arrive at an air conditioning company's site. One has not chosen a unit and wants a survey for a room. The other has a unit installed and needs a fault logged. A single contact form drops both into one inbox, and the ordering breaks there. The tangle shows when a season opens and requests climb at once. Around Kaynarca and Çamçeşme in Pendik the question is the same: where does the split happen? On Diotek the two live in one application without ever becoming one queue: the split happens at the door, and the records are shaped differently.

Get a quote Tell us about your project

CRM — Pendik

Pendik holds small manufacturers and multi-site service outfits side by side. When a spring installation returns as a maintenance record in autumn, the first hot week puts both request types on the same line. The work closest to this district's sector profile is Diotek, written for air conditioning. Where it does not overlap: quote preparation, contract tracking and funnel reporting sit outside what we can show. What carries across is where the record is separated — a survey request centres on a place and a date, a service request on an installed unit. Marketing pages and request screens sit in one Laravel application; Inertia handles page transitions on the client, MySQL holds the records, Redis caches the season's traffic and Tailwind shapes the screens.

  • A survey request opens before any unit is chosen: it carries a place and a date and never asks for an installed device.
  • A service request is written around the installed unit, so a request arriving after hours lands as a record instead of a note beside the phone.
  • Both live in one Laravel application and neither drops into the other's queue; the marketing pages share that code base, so no second panel is opened.

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

Diotek — survey and service requests in one application, never in one queue

An air conditioning business takes two kinds of request through its site: a pre-sale survey appointment and post-installation service, built as separate flows from the start. A visitor can ask for a date for a room before choosing any unit, and that request never joins the queue of maintenance and fault records opened against an installed device. On the service side the record stays written, so an after-hours request does not depend on a note taken by phone. Marketing pages and request screens sit in one Laravel application, with Inertia moving pages on the client and the request record sharing a MySQL schema with the content.

Read the case study →

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

  • Could we not simply put two forms on the site?

    A form is the surface. The question is whether the two records are shaped differently and whether they stay in separate queues after they are submitted. Two forms writing into one inbox is still one queue.

  • Requests spike the moment the season opens. What happens then?

    The same code base carries it, with a Redis cache in front of the pages read most. We are not putting a load figure in this answer; we do not publish numbers whose source we cannot show you.

  • Do you come out and look at the site in Pendik?

    There is no office and nobody travels for setup. The first thing we do is written: which request type carries which fields, and where each one goes once it is submitted.

  • We also need quotes and contract tracking.

    That is not what Diotek shows, so we do not promise it here. Booking flows that change by sector are something we are handling in our own product, AlgoRandevu, and it is still under construction rather than finished.

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