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

CRM for Catalca businesses

Where goods are sold by measure, the purchase line on a customer record can easily be half written. The product name goes down; the amount does not. Yet at the counter the amount is what sets both the price and what is left on the shelf. Along the shop row at Kaleici in Catalca, and on market day, the amount is what a purchase line has to carry. Kokudankokuya was built around the measure instead: the sellable unit sits one step below the product, on the size.

Get a quote Tell us about your project

CRM — Catalca

Catalca trades on food retail and country commerce. Merkez Kasap really is in Catalca and we wrote its QR menu, and Catalca is the only district where that holds. That job was a menu page, though — it holds no customer record. The evidence here is Kokudankokuya, and its boundary belongs here too: a fragrance store, so service history, bookings and multi-step plans were never built into it, and we have never written farming or livestock software. What carries across is where the sellable unit sits. The store runs on Laravel and MySQL; its catalogue never called for a separate search or cache layer.

  • The sellable unit sits one step below the product: the record keeps the scent, while price and stock ride on the size, so adding a size never means opening another product.
  • The catalogue carries a second axis, scent family and note, so a customer who knows no brand name can move from character to product.
  • One perfume can hang off several notes, so a single record is not shut inside one branch of the tree and turns up from different searches.

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

Kokudankokuya — the sellable unit rides on the size, not on the product

A store we wrote for fragrance retail. One decision holds it together: the scent stays a single heading in the record while sizes become separately sellable units. Because price and stock are tracked on the size, adding one never means opening another heading in the catalogue. Beside the category tree, scent family and note open a second way to move through the range, and one perfume can hang off several notes, so the same record surfaces from different intents. The catalogue never called for a separate search or cache layer; the store sits on Laravel and MySQL. Boundary: no customer history, no booking, no service record.

Read the case study →

Working with Catalca 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 actually have a client in Catalca?

    We do. Merkez Kasap is here and we wrote its QR menu, and Catalca is the only district where we can put a client's name beside it. That job was a menu page, though, with no ordering and no customer record behind it.

  • We sell by the kilo. What does a fragrance store tell us?

    The measure is the shared part. On Kokudankokuya price and stock ride on the size rather than the product. In a shop selling by weight the sellable unit is the amount, not the name, and a purchase line that hides the amount leaves the history incomplete.

  • Do you write software for farms or livestock?

    No, and we never have. With nothing to show in that field we make no promises about it. What we can describe is the catalogue, the measure and the shape of the record.

  • We want customer history. Does store software give us that?

    Part of it. A store record holds what was sold, but service history, bookings or a multi-step plan are records written separately. We draw the line first: none of those exist in Kokudankokuya.

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