We build the software a dealership, a showroom and an authorised service centre run their own business on: vehicle or product stock, the showroom sales process, service appointments and work orders, warranty claims and integration with manufacturer-side systems come together in one structure. Your existing accounting package stays where it is, and the source code is yours.
A dealer's day is not made up of a single kind of work. On the same day a customer walks into the showroom, a used vehicle or machine is taken in part exchange, a work order is opened in the service bay, a spare part is requested from the store, a warranty file is sent to the manufacturer and the till is closed in the evening. In most dealerships each of these sits somewhere different: sales in an Excel file, the service appointment in a diary, parts stock in the storeman's notebook, the warranty file in an email folder. Nobody withholds information deliberately, but nobody can see the full picture either. When someone asks at month end how many days it took to sell a vehicle, whether the service department covers its own costs, or how much of the warranty receivable due from the manufacturer has actually been collected, the answer comes from an estimate rather than a measurement.
One source of this confusion is that the terms get tangled together. The dealer ordering portal set up by the manufacturer and the dealer's own operating software are not the same thing. The portal solves the side that flows from manufacturer to dealer: price lists, campaigns, account balances, placing orders, shipment information. A Dealer Management System solves the inside of the dealer's own shop: which vehicle or product is waiting in stock, which advisor is handling which customer, which work order is open in the workshop, which part was fitted, which warranty claim is awaiting approval at the manufacturer. The B2B dealer system page on our site describes the first side; this page describes the second. The two can run side by side in the same company, and in practice they often do; in that case product and account data is fed from a single place.
A Dealer Management System ties these scattered headings into a single chain of records. An incoming customer becomes an enquiry record; the enquiry is linked to a quotation, the quotation to a sale, and the sale to delivery and the start of the warranty period. The chassis or serial number of the vehicle or machine is the shared key in this chain; the same number comes back when a work order is opened in service, and the operation carried out and the part fitted are written against it. So when the customer walks through the door two years later, the history is not something people try to remember, it is something they read. The same chain also makes visible the places where sales and service feed one another: the list of customers whose scheduled maintenance is coming up, products whose warranty period is about to end, vehicles that have been standing in stock for a long time while their cost quietly grows. These lists are outputs the record produces by itself, not something anyone has to prepare separately.
There are two boundaries we have to state up front on this work. First, some brands contractually oblige their dealers to use the brand's own systems; we are not offering to replace those systems. In such a case, the software we build becomes a layer that runs alongside the mandatory system and collects the work it does not cover. Second, connecting to systems on the manufacturer (OEM) side is not a one-sided decision; integration is only possible to the extent of the service, file format or authorisation the manufacturer provides. We investigate whether it is possible during discovery, and if it is not, we say plainly that the solution will be file-based or manually fed. Official procedures such as notary transactions, registration and insurance are subject to their own legislation and their own competent authorities; we do not go into those areas.
Businesses running new and used vehicles together, taking part exchanges and carrying stock cost. When the purchase price of a vehicle, its preparation and maintenance spend, its time standing in the showroom and the profit on the sale do not appear in the same record, a sale assumed to be profitable can turn out to be a loss. The system keeps this calculation per vehicle.
Service operations where appointments, work orders, labour and parts usage run on paper. When how much of the workshop's capacity is taken and why a particular job is waiting are not visible, the delivery time promised to the customer keeps slipping. Whether the service department covers its own costs also only becomes measurable once work order records have built up.
Dealers who go on providing service and spare parts for the machines they sell for years afterwards. The real value here is serial-number-based history: what was fitted to which machine, which fault keeps recurring, whether the warranty still applies. If that history is not recorded, it sits only in the memory of the long-serving technician and disappears when they leave.
Companies operating more than one showroom, warehouse or service point. Losing a customer at one branch while the stock waits at another, transfers between branches going unrecorded, and branch-level profitability being unknown are the most common problems. Shared stock visibility together with branch and role-based permissions puts this picture right.
Every vehicle, machine or device is held as a unique record; purchase cost, preparation and maintenance spend, the branch it sits at, its time in stock and its status are written against that record. Instead of stock that counts units in bulk, a structure is built in which each unit carries its own history. After the sale, the same number is used as the key in service as well.
An incoming customer enquiry is recorded and assigned to an advisor; the quotation, any part-exchange valuation and the finance note come together in the same file. Which enquiry is at which stage and with whom becomes visible. The quotation document and the sales contract are generated from templates; the reason for lost enquiries is flagged separately, accumulated and reported periodically. That way, which objection keeps recurring emerges over time.
Appointments are planned by service type, technician and work bay; the workshop's used and free capacity is visible in the calendar. The delivery time given to the customer stops being a blind guess. When a delay occurs, whether it came from a particular job, a wait for a part or a delayed approval is read from the record, and the recurring causes are isolated. Appointment details can be sent to the customer by SMS.
The operations carried out, the labour time spent and the parts fitted are posted to the open work order; parts used are deducted from stock. When additional work arises, customer approval is tied to the record and the argument over verbal approval disappears. When the work order is closed, the items making up the amount charged to the customer and the cost of the job to the dealer are visible on the same screen; a single explanatory document is produced for the customer.
Work covered by warranty is flagged separately; the stages of submission to the manufacturer, approval, rejection and collection are tracked. Because the reasons for rejected claims accumulate, it becomes clear which document or which piece of information is persistently missing. The warranty receivable therefore stops being an item forgotten because nobody was following it, and the amount outstanding becomes visible.
Parts stock is run with barcodes or QR codes; minimum levels, a critical parts list and order proposals are maintained. Because service consumption and purchasing look at the same data, the part that constantly runs out is separated from the part that has been sitting on the shelf for years. Parts are matched to the model and serial number they belong to, which reduces issuing the wrong part.
With branch and role-based permissions each user sees only their own area; critical actions such as discounts and cancellations are written to the audit log. Sales, service and parts movements are transferred to the accounting or ERP package you use and connected to the e-Fatura and e-Arşiv (Turkish e-invoicing) flow. Stock transfers between branches also run through the same record. We do not replace your accounting package; we feed it data.
We work the process out from where it is done, not from where it is described. A day in the working life of the sales advisor, the storeman and the service technician is observed; which record is kept where, which information is entered twice and which job runs entirely on one person is written down. Scope and order of priority are then agreed together on the basis of that observation.
The chain running from enquiry to delivery and on to service is designed; where the chassis or serial number will act as the key and which fields will be mandatory are decided. The data in existing Excel files and notebooks is reviewed; we decide together what will be migrated and what will remain only as a historical archive. That decision directly shapes the rest of the project.
We do not change the whole dealership at once. We start with the module that hurts most, at a single branch and on real work. During the pilot the old method runs in parallel for a while; paper is not abandoned entirely until the system has proved reliable. This stage is usually a few weeks of real use, and at the end of it the scope is reviewed again.
Work orders, parts stock and the warranty flow go live; accounting, e-Fatura and, where possible, the manufacturer-side system are connected. The limits of the integration become clear at this stage; what will be transferred automatically, what will run manually and which system is the master source for which data are fixed in writing. That document becomes the shared reference for later discussions.
The remaining branches are opened in stages. User training is given by role and a short written guide is left behind. After go-live, maintenance and support continue; as the business changes the modules are updated and new requirements are prioritised into the queue. Source code, database and documentation are handed over to you, and no locks are left behind.
No. If the brand contractually requires a system, it stays where it is; we are not offering to replace it. The software we build usually collects the areas that system does not cover: part-exchange and used stock cost, workshop capacity, branch-level profitability, your own customer history. During discovery we separate out item by item which work stays in which system, and draw a boundary where the two do not overlap.
That is not a one-sided decision. Integration is only possible if the manufacturer offers a service, a file format or an authorisation; some brands do, others do not. We investigate this during discovery and write down plainly what is possible and what is not. If it is not possible we continue with file-based transfer or manual entry, and we say so from the outset. We would advise you to treat any proposal that promises integration in advance with caution.
It is a difference of direction. A B2B dealer system is the portal the manufacturer sets up; the dealer sees the price list there, places orders and follows their account balance. A Dealer Management System is the software the dealer runs their own business on: showroom sales, service work orders, warranty, branches and the till. One solves trade between companies, the other the dealer's internal operation. Both can be used together in the same company; in that case product and account data is fed from a single place.
Yes, and that is how most of our projects start. Because we work module by module, you can bring stock and showroom sales live first and leave service until later. We do, however, build the data model from the start so that it covers service too; the chassis or serial number is held as the key from day one. Otherwise, when service is added, no link can be made to past sales and the data has to be reworked a second time.
No. These procedures are subject to their own legislation and their own competent authorities; official registration, notarised sale, issuing an insurance policy or querying damage history are outside our scope. What the system does is record the outcome of these procedures and show which document is missing in the process. Where access to official data sources is required, that access has to be held by you under formal authorisation; we cannot obtain it on your behalf.
Chassis or serial number based stock and customer history; the showroom sales and quotation flow; appointments, work orders, labour and parts usage; warranty claim tracking; spare parts stock; branch and role-based permissions; the accounting and e-Fatura connection and branch-level reports. Source code, database and documentation belong to you; you can continue with another team whenever you wish.
In a 30-minute discovery call we listen to what you need and tell you honestly whether custom development or an off-the-shelf product is the better answer.
For companies whose sales run through dealers, distributors and solution partners we build channel software: partner records and tiering, target and commission calculation, lead sharing and conflict prevention, marketing collateral, and training and certification tracking are brought together in one place.
Details →We build a system that runs the work of your field reps from a phone: route and visit plans, mobile ordering, in-field collections, shelf and competitor photos and target tracking all come together in a single app. The app also works without an internet connection and synchronises by itself once the connection returns.
Details →We unify the customer data held on your website, e-commerce platform, CRM, call records and in-store tills under a single identity. Duplicate records are matched, segments are generated by rule, consent status travels with every record, and segments are pushed to channels in a controlled way. The aim is not another report, but a working customer view that the channels can use every day.
Details →We turn email, SMS and WhatsApp messages from announcements sent one at a time into flows that run themselves according to what the customer does. Abandoned basket, welcome, win-back and post-purchase flows are built; people who show interest are scored and handed over to the sales team. Consent and sending discipline are built into the flow itself.
Details →We build a learning management system (LMS) that brings together, in one place, the training catalogue, who is required to take which course, who has completed it and when a certificate expires. When an audit asks for the record of your health and safety and quality training, it comes out on a single screen rather than after hours of searching.
Details →We build a system that ties the company goal to team and individual goals and bases the end-of-period review on records rather than memory. Goal management runs on OKR and individual assessment on a performance management system (PMS); we keep the two side by side on the same platform without mixing them up.
Details →
