Get a quote

Enterprise & Commercial Software · Sisli

Enterprise & Commercial Software for Sisli businesses

Requests reaching a brand's corporate site along Halaskargazi are not one kind of thing. Some come from a party that has not bought yet and wants a survey, a visit, a quote. Others come from a party that already bought and needs something installed put right. Drop both into one contact form and a person triages them by reading free text. Enterprise software in Sisli therefore starts as a question about queues rather than themes. On Diotek the split sits in the flow rather than in the form.

Enterprise & Commercial Software — Sisli

Sisli's centre of gravity is the brand shopfront: around Halaskargazi and Fulya a head office and a selling floor sit on the same stretch, with cosmetics retail and treatment services at neighbouring addresses. In that shape a corporate site is both a showcase and an intake door. The closest match in our portfolio is Diotek. Where it does not overlap is plain: it was written for the air conditioning and ventilation trade, and we have nothing to show on cosmetics selling, salon operations or in-store campaign management. What carries across is the shape of a request — which queue it belongs to is decided as the record opens, not read off afterwards. Laravel, MySQL, Redis, Inertia and Tailwind make up the stack.

  • A survey request opens in a flow of its own: a visitor asks for a date for the space before picking any unit, and the request reaches operations without joining the service queue.
  • Maintenance and breakdown requests arrive through a second flow built around the installed unit, so the record stays written down instead of living in a phone note.
  • A request sent outside working hours still lands as a written record, and at the start of a season the two request types reach operations already separated.

Why Algoriel

  • Many institutions, one system

    Vipkurum runs seven institutions on the same system while each one keeps its records to itself.

  • Adding one adds a boundary

    Each Vipkurum institution signs in at its own domain under its own brand, so adding one does not mean a second installation.

  • Each branch runs its own work

    A branch marks its own exam sheets, so one broken device does not stall every institution at once.

  • Each role, its own view

    Timetable, exams, students, parents, payments and reporting sit on one platform, and who can see what is settled up front.

  • Each institution signs in through its own domain

    At Vipkurum, seven education institutions open under their own address and their own brand, and the name of the software never appears on a user's screen.

  • No reinstallation for a new institution

    Adding one more institution means writing a definition. No second copy of the system is stood up, and the maintenance stays in one place.

  • Office and field on the same record

    AlgoKlima's office panel and field app read and write the same record. A technician closes the job where there is no signal, and the entry reaches the office panel once the connection returns.

  • Operational and commercial records close together

    At AlgoCar the service record and the commercial record sit in the same system, so the cost of a job and its revenue are not reconciled across two programs.

  • One institution's data stays closed to the next

    Student, parent and payment records stay inside the boundary of the institution they belong to. That boundary is how the system is set up, not a view switched off on a screen.

  • One technical footing we can maintain for years

    Nothing goes into your system that the team maintaining it does not already know. AlgoKlima and AlgoCar are our own products, built on that same footing, and we work on it every day.

Work like this

Enterprise & Commercial Software · Case study

Diotek — a survey booking and a service call run in separate queues

In the air conditioning and ventilation trade a site takes in two kinds of request: a survey booking before the sale and a service call after installation. Diotek keeps them apart from the start. A visitor asks for a date for the space before choosing a unit, and that request travels its own way into operations instead of joining the service queue. Maintenance and breakdown requests open from the site around the installed unit, so the record is written down, not remembered. At the start of a season the two types arrive already separated. The scope stops there: in-store selling, stock movement and campaign management sit outside it.

Read the case study →

Working with Sisli 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 corporate site has one contact form. Is splitting it really necessary?

    It is once the kinds of request differ. With a single form, someone orders the queue by reading free text, and when that person takes leave the ordering leaves with them. On Diotek the split is set as the record opens, so a survey booking and a service call arrive on separate queues.

  • We sell cosmetics, not air conditioning. What does that project say to us?

    The sector does not match and we say so plainly. What matches is the shape of the request: an enquiry from someone who has not bought and one from someone who already has should not land in the same queue. Rename the queues and the split still holds.

  • Traffic piles up at the start of a season. Do the public pages and the request screens slow down together?

    On Diotek both run on one codebase and a Redis cache absorbs that opening traffic. Corporate pages and request screens come off the same Tailwind scale, so a busy period does not create a second interface to maintain.

  • You work remotely. How do you map this flow without visiting the selling floor?

    There is no office on our side and the whole job runs remotely. We map the flow by writing it rather than watching it: which field a request arrives with, which queue it drops into, who closes it. Those three answers decide the shape of the record.

How many institutions and branches should we plan your system around?