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

CRM for Ankara businesses

On the head-office floors around Cukurambar and the Eskisehir road, a first enquiry can arrive through a switchboard. Someone describes a problem, someone else writes a note, and which unit that note belongs to gets decided later in the day. That is the first question behind CRM software in Ankara: who does the sorting. On Diotek nobody does. A request reaches operations on the flow it entered through, so the order holds, and one written after hours still lands as a record.

Get a quote Tell us about your project

CRM — Ankara

The weight in this city sits in the management layer: a head office, a few units under it, and one corporate site acting as the shared front door for all of them. When the door is shared, everything lands in the same place, and whoever separates it becomes the tiredest link in the chain. The portfolio work closest to that way of working is Diotek. Where it does not overlap should be said plainly: Diotek was written for air conditioning and ventilation. Approval steps inside a multi-unit institution and internal routing rules are not things we can show. What carries across is not the sector but the moment classification happens. Underneath, Laravel runs the flow, MySQL holds the records and Redis the cache, with Inertia and Tailwind on the interface.

  • A survey booking and a service call open as two flows, and because they never share a list, nobody sorts the queue by hand.
  • Request entry does not depend on a phone line: something sent after closing time still lands as a written record on its own flow.
  • The request record and the marketing content share one MySQL schema, so a page edit and a request flow are not two systems to maintain.

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 — requests separate as they enter, so operations sorts nothing

An air conditioning and ventilation business takes two unlike requests through its site: a pre-sale survey booking, and service after an installation. We set them up as separate flows from the start. A visitor can ask for a date before choosing any equipment, and that request reaches operations on its own flow rather than the service queue. A maintenance or fault request opens around the installed unit instead, and stays a written record rather than a phone note. Marketing pages and request screens share one Laravel application: Inertia moves pages on the client, routing and validation stay in Laravel, Redis carries the season.

Read the case study →

Working with Ankara 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 head office is in Ankara. How would working with you actually run?

    We keep no office and work entirely remotely. The first deliverable is written rather than built: how many kinds of request the site receives, and which unit answers each one. Development starts once that list exists.

  • Everything already comes through one contact form. What is wrong with that?

    The form is not the problem; the deferral is. When one box takes everything, a person classifies it by hand, and the queue stops when that person is away. Separating at entry removes the dependency rather than the form.

  • Could an off-the-shelf CRM not do this with tags?

    It can, and we say so instead of quoting a build. The difference is what a tag is: an attribute added after a record exists, where a flow decides the rules the record is created under. Once the request type also sets which fields are required, tagging stops being enough.

  • Diotek is an air conditioning business and we are not. What does it tell us?

    We name the sector as it is; what travels is the shape of the entry, not the equipment. One caller wants a date for a site visit, another has a unit already installed and needs it looked at. Whatever the institution, those two cannot share a queue.

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