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 we write is transferred to you as defined in the contract.
Prepared by Pan Innovation House, a software company based in Gaziantep, Türkiye · Last reviewed:
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.
Not every dealership needs custom software. The table below sets out five common routes side by side: when each is enough and where it struggles. If your brand requires its own system, that system stays; the real question is where the work it does not cover should live. We ask the same questions during discovery and say so plainly when an off-the-shelf option will do.
The choice mostly depends on how many branches and brands you run, whether you operate a workshop, and what your brand's own system already covers.
| Route | Enough when | Where it struggles | Cost structure |
|---|---|---|---|
| Spreadsheets, a diary, notebooks and WhatsApp | A single site with modest sales and service volume, where a few people hold the information. | Per-vehicle cost and days in stock, customer approval on work orders, warranty receivables and serial-number history are either not kept at all or kept by hand in separate files that do not connect; knowledge stays with individuals and month-end figures are estimates. | Low upfront cost; the hidden cost is labour, untracked warranty receivables and bad data. |
| Modules of your accounting or ERP package (Logo, Mikro, Netsis, SAP Business One, etc.) | Accounting records of sales and parts movements (invoices, delivery notes and stock entries) are all you need; you do not need to track the showroom pipeline or workshop planning separately. | Per-chassis vehicle costing, part-exchange valuation, workshop capacity and warranty claim tracking vary by product and version; they may need an add-on module, a partner solution or customisation. Ask your software vendor. | Add-on module and customisation on top of your current licence. |
| The system your brand provides or requires | The brand expects ordering, warranty and reporting to run through its own system, and most of what you need sits within it. | What it covers varies by brand; work that falls outside it, such as other brands' vehicles or used stock, still has to be kept somewhere else. Ask your brand what is in scope. Where customer data may be held is governed by your dealer agreement and your data protection obligations. | Set by your dealer agreement with the brand. |
| Off-the-shelf dealership and workshop software | Your process is close to the flow the package assumes; speed of rollout matters most. | Multiple branches or brands, long serial-number-based service histories for machinery, or your own warranty and approval rules may not fit the package; what can be customised varies by product and version. | Licence or subscription, plus customisation. |
| A custom DMS layer built for your dealership | You want sales, service and warranty on one chain of records, while your accounting package and any brand-mandated system stay in place. | Discovery and rollout take longer and the upfront investment is higher; each branch needs someone who owns the data, and running the old method alongside the new system during the pilot takes extra effort. | A project fee and a maintenance agreement instead of per-user licences. |
The source code we write and your data are handed over to you as defined in the contract; third-party and open-source components remain subject to their own licences.
Each row involves two decisions: which system holds the master record, and how often the data moves to the other systems. The master is drafted during discovery and fixed in writing when the integrations are connected. The frequencies below are a typical starting point, not a fixed design.
| Function | Why it needs deciding early | Where the data comes from and goes | How often |
|---|---|---|---|
| Stock record per chassis or serial number | Every other row links to this record; until you decide whether the master record lives in the dealer system, in accounting or in the brand's system, the rest of the data flow cannot be designed. | Purchase invoices and costs come from accounting or are entered on intake; branch and status are held in the dealer system. | Immediately, on every purchase, transfer and cost entry. |
| Enquiry, quotation and part-exchange valuation | Unless you choose up front whether the sales invoice is issued from the dealer system or from your accounting package, the same sale may end up being entered twice; where the part-exchange vehicle's purchase record is opened is decided at the same time. | Starts in the dealer system; once the sale is confirmed, invoice data goes to accounting. | When the sale is confirmed; in real time or as an end-of-day batch, depending on the accounting connection. Because the vehicle sales invoice may be needed at handover and registration, real-time transfer is recommended for it. |
| Brand price lists and campaigns | A quotation built on an outdated price list or an expired campaign has to be corrected later; how the list is updated, and by whom, needs to be settled from the start. | The brand's portal or system is the master; where no connection is available, the list is loaded from a file. | Whenever a list or campaign changes. |
| Appointments, work orders and customer approval | If it is not defined up front whether a work order is opened as customer-paid, warranty or internal, service invoices, warranty claims and vehicle costs get mixed up. How customer approval for extra work is obtained is settled here too; approval recorded when extra work comes up leaves a record to refer to if consent is later disputed. | Held in the dealer system; a closed customer-paid work order goes to accounting as a service invoice and into the e-Fatura or e-Arşiv flow (Türkiye's e-invoicing); warranty work orders link to the warranty claim, and internal ones to the vehicle's cost. | When the work order is closed. |
| Spare parts stock | If parts are ordered through the brand's system, the two stock counts may not agree; unless you agree at the outset which one is authoritative, reconciliation has to be done by hand every month. | Parts issued are booked against the work order or a counter sale; purchases are matched with accounting or the ERP, and with the brand's system where parts are ordered through it. | At the moment of issue; reconciled with accounting at the end of the day. |
| Warranty claim tracking | How claims reach the manufacturer depends on what the manufacturer offers, and is investigated during discovery; until that is known, neither the mandatory fields on the claim screen nor the way warranty receivables are followed in accounting can be designed. | Raised from the work order; sent to the manufacturer by API, file upload or manual entry (for example on the manufacturer's portal), as the manufacturer allows; the payment is reconciled in accounting. | Per claim; on the manufacturer's side, depending on the connection it offers. |
Frequencies are a starting proposal; they are adapted during discovery to what your accounting package and your brand's system allow, and confirmed when the integrations are connected.
If these are ready, the first call is concrete and the scope of discovery can be written more precisely. Anything missing we complete together during discovery.
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 as defined in the contract.
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; starting this way is usually the lower-risk route. 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. The source code we write and your data are handed over to you as defined in the contract; third-party and open-source components remain subject to their own licences. You can continue with another team whenever you wish.
A dealer management system (DMS) is the software a dealer, showroom or authorised service centre uses to run its own business: vehicle or product stock, showroom sales, service bookings, work orders, spare parts and warranty claims sit in the same chain of records. The common key of that chain is the vehicle's chassis number or the machine's serial number; after the sale, the same number is used in service. Your current accounting software stays in place, and sales, service and parts movements are passed to it.
Car service software keeps the service booking, the work order, labour time, the parts fitted and the breakdown of the amount charged to the customer in a single record. In our set-up, bookings are planned by service type, technician and work bay, parts used are deducted from stock, and the customer's approval is recorded when additional work comes up. Warranty work is flagged separately, and the approval, rejection and collection stages of the claim sent to the manufacturer are tracked.
We listen to what you need and tell you whether custom development or an off-the-shelf product fits better. The first 30-minute call is free; the scope of an on-site discovery, and its fee if any, is agreed in writing during that call.
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 →
