Last year I worked as a consultant for an automotive service centre in Konya — 38 employees, a busy workshop, and a straightforward request from the owner. ‘We want a customer tracking program,’ he said. ‘People come in, leave, come back — but we have no idea who visited how many times, what work was done, or when to follow up.’ He had diagnosed the problem correctly. But the problem was not the program. Customer names were written in a notebook. Some service forms were filled in; others sat on a shelf, untouched. No matter how good a piece of software you install in that environment, it stays empty.Here is my argument: the technical side of downloading and setting up an open source CRM (customer relationship management) program is now something almost anyone can do. The real work is productisation — shaping the program to fit the way the firm actually operates, changing the daily habits of the people who will use it, and giving the owner a clear answer to the question ‘why would I open this program every morning?’ Skip those steps and the software will be switched off within three months, cost and effort wasted.A CRM program keeps all customer information in one place. Who called, what they needed, when they visited, what was agreed — all of it recorded. That way, when a salesperson leaves, the next person can pick up the relationship without starting from scratch. The concept is not new; larger companies have been doing this for years. But in small and medium-sized businesses, the habit of recording almost never exists. The owner carries everything in his head, or one experienced employee knows everything. When that person leaves, the knowledge leaves too.Open source CRM programs are software whose underlying code is visible and modifiable by anyone. Several programs of this kind began to appear around 2003 and 2004. Their biggest advantage was simple: no licence fee. Download the program, install it on a computer, start using it. For an automotive service centre in Konya, the technical setup was entirely possible. But what I found at that firm was that the technical part was the smallest piece of the problem. The program was installed — and nobody entered any data. When a customer arrived, the service assistant looked at his paper form. ‘I do not have time to type this into the system,’ he would say. The paper form habit was decades old; the program was a stranger.This is where productisation becomes the actual job. Turning a program into a product means first understanding how the firm works. Then you simplify the program to match that reality — removing fields that are never relevant, putting the essential ones at the front. In Konya, the customer record screen had twenty-two fields. I cut it to fourteen. Eight fields were things the service assistant did not need to fill in every morning, and they were cluttering the screen and creating anxiety. After cutting them, the reaction was: ‘All right, we can manage this.’ But I should be honest about what that cost: once those fields were gone, certain reports became incomplete. The owner asked in the first week, ‘Where is the mileage record?’ That tension is real — the easier you make data entry, the thinner some of your reports will be. Every project involves finding that balance.Simplifying the program is not enough. You need small, concrete steps to make data entry a daily habit. In Konya, we removed the paper service form entirely. When a customer arrived, the assistant had to look at the program — there was no paper alternative. The first two weeks were very difficult. By the third week, assistants were opening the program on their own: ‘A customer just came in, let me check the old service record.’ That transition took roughly six weeks. One employee left during the process — ‘I cannot deal with this computer business,’ he said. The rest stayed. By the end of six weeks, daily entry was normal.Clarifying what the owner expects to see is essential before anything else. This owner had three questions he wanted answered every morning: how many vehicles are in the workshop right now, how many were serviced in the first half of this month, and how many customers from last month have not come back yet? Those three questions were extremely useful to me. They told me exactly which screens mattered and which reports had to work reliably. I built the reporting section of the open source program around those three questions. The screen the owner opened first thing every morning gave him those three answers. Everything else stayed in the background. If he had opened the program each morning and found nothing that made sense to him, he would have abandoned it within a month.There is a real difference between installing an open source program for one firm and making it ready to sell to other firms. To become a sellable product, three things are necessary. First, the installation must be repeatable by someone else — the consultant cannot spend months on site every single time. Second, there must be a user guide: in Turkish, plain language, with screenshots. Third, it must be clear what happens when the owner changes or a new employee joins. For Konya, I prepared all three after the initial rollout. The installation steps fit on four pages. The user guide came to eight pages. Without those documents, taking the same program to a different service centre would have meant explaining everything from the beginning, every time.If I had to put what I learned from this Konya project into a single sentence, it would be this: the value of a customer tracking program lies not in its features but in the firm’s discipline around entering data. Today the owner of that service centre tells me: ‘I can now see exactly which parts were replaced in a car that came in last October.’ That sentence is the result of a habit change, not a software feature. If you are thinking about investing in a similar program, start with one question: where does my team write down customer information right now? If the answer is ‘nowhere’ or ‘on paper that gets lost,’ plan how you will change that habit first. Bring the program in after that decision is made.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 17, 2004. The English edition has been reviewed and edited by the author.