The bigger the company, the more difficult it is to control its operation. When processing an order even the most responsible managers can forget to call a client back, calculate the price of an order, or simply lose it.
From this case you will learn how the introduction of CRM into a huge plant helped to increase both the sales and productivity of managers. We will also tell you about the instruments we have used to design a system as well as the many complexities we have faced.
Prehistory
We received an application from a Production Director working for “Ekipazh” plant, the biggest producer of plastic and steel windows, doors, rolladens, and aluminum constructions in Eastern Ukraine. The plant manufactures 1,000 units daily and has over 3,000 points of sale.
The plant was working in a traditional way with dealers calling managers to place orders, and following up with information about those orders through e-mail. To learn their order status, dealers had to call managers again.
In the case of bulk orders, phones were almost constantly ringing. With such a number of calls it was easy to miss or forget something, thus managers used to be exposed to constant stress.
Task
Optimization of plant’s business processes and reduce load upon managers working with dealers. Creation of an efficient instrument for managers to process orders.
Decision
After long-term negotiations and jumping into the task we took the decision to develop CRM. It is an application software building counteraction with clients at the unified standard: it fixes inquiries and distributes them between managers, keeps financial records, clearly identifies the work of each manager and analyses sales.
Difficulties
“Ekipazh” plant worked with two accounting systems simultaneously, which resulted in an additional complexity during CRM development – it was necessary to provide synchronization with both systems.
Resources and Terms
We developed this software complex from scratch. Thus, prior development term was set to 4-6 months. We tackled the task and determined a start-up budget. However, working on the program, the customer took the decision to extend the system’s functionality and make it more flexible considering future needs. This required additional resources; that is why the term and budget were increased.
Who was Engaged in the Project
We gathered a team and started working. The following specialists were engaged:
Project manager
UX specialist
UI specialist
Art-director
Back-end developer
Front-end developer
DevOps specialist
Q/A engineer
CTO
It is possible to design an efficient CRM only if fully immersed within a client’s business. It requires close cooperation with the customer’s team. We managed to find common language with the team, which included; Production Director, heads of departments, and technical specialists… Everybody participated in the project.
Work Results
CRM introduction resulted in making the plant’s operation faster, for example; managers stopped “hanging” on the phone and had more time to work with dealers, dealers could easily track their order status and communicate with managers. All processes turned transparent.
Process participants counteraction scheme
Several types of users interact within the system: dealers, claim managers and a content manager. Each system participant can see and work only with the information, which directly connects to him or her. Dealers can see information on their orders, financial department, mutual settlements, and client payments, while claim managers can see only claims. A dealer no longer needs to make ten calls as he can track all the information on his order via the system.
The process itself is as follows:
An order is made in a shop by means of the construction software.
This order is processed into the section of the program dealing with the plant’s orders.
Then the plant’s engineer must make certain that everything was transferred without errors and approve the order. Afterwards, the order synchronizes with our system with the status “Accepted” and becomes available to dealers.
Further, each dealer tracks his order execution status. After the shipment of the order he can see the route his cargo will be delivered by, delivery date, and even details of a driver.
All mutual financial settlements, opening balance, compensations and delivery payment are available to the dealer.
In case of any failures with the order the dealer submits a claim, which will be treated by a specialist.
Now all production processes are in due order, and the work is performed faster
Specific functional aspects are developed for every process participant
Interviews and Sketches
CRM must reflect an existing business process and speed up and simplify it at the same time. For this you must fully understand how everything works and how process participants interact. To understand the process better we have organized a series of interviews with top managers as well as with employees from different departments of the plant; production, IT, and accountant. Separately we communicated with dealers.
We learn each detail thoroughly. Only by this it is possible to create a useful program
After having studied completely how everything worked we built up a process at the upper level.
Writing interaction scenarios
Sketches are already made. We look through the key scenarios. Then we call the client and discuss them
Creation of a prototype
We start creating an interactive prototype. A prototype is a demo version of our future program. It can be compared with a car test drive: a customer can learn everything, try and find out how the system works. If some details were missed, this stage will show at once what must be improved in particular.
The prototype simulates everything from future CRM. It makes clear what and how everything will work
We present everything to the client and finish all the details by changing wording, information priority and writing notifications order. In addition, we communicate with dealers
Design Conception Development
The CRM system design had to be associated with the corporate identity of “Ekipazh” and with their website style. Entering the application administration panel, a dealer must understand that he is at the right place.
Creating a concept it is important to remember about one useful action: which problem the design will solve. At this it is necessary to consider an existing prototype as well as how the design will look on different screens. And since we implement the design in the code, a designer shall interact with the technical team at each stage of the project.
The plant provided us with their brand book containing their corporate identity, e.g. logo, posters and working hours. Using these materials we started preparing an inspiration board being some kind of a preview for the future design. Inspiration boards help to understand the spirit and mood of a project. We used photos of the plant, shops facades, current site pages and billboards for this inspiration board. We accumulated all that on one board and learned how the clients perceived corporate colors of the plant.
Inspiration board is a preview of the future design
We prepared two concepts. Both of them corresponded to the requirements given by our customer.
Concept 1
We used colors coinciding with the colors of the company’s logo. Basic color was a strong dark brown.
We chose orange as a contrast color. It must have been maximum contrasting and show up advantageously on the main color background.
The chosen sections and elements as well as buttons to press were highlighted with an accent color. This would help a user to make sense of interface opportunities faster.
We used a font of blue color for clickable links, such as “Order” or “Delivery date”, this is more common for web application users.
Each status had its own color for the user to see immediately which status his orders or claims have. All these colors are perfectly combined with principal interface colors and are in harmony with the general concept.
Concept 2
As in the first concept, we chose the colors used in the logo as the basic ones and prepared an inspiration board (site logo, photos of the plant and other elements of the corporate style).
Main color was dark blue.
Contrast color was orange, brighter than in the previous concept. It showed up maximum advantageously on the principal color’s background.
We used accent blue color, common for every user, for clickable links font.
Each status received its own color.
Table lines had different backgrounds for the user not to confuse his orders.
Both design concepts are comfortable for users: links are highlighted with common blue color, orders are separated
In addition to work with orders and finances there are “restricted pages”, e.g. information from the plant, administration panel settings, notification settings and guide. We worked on them thoroughly as well to make them comfortable and intuitively comprehensive.
We made restricted pages simple and comprehensively intuitive
Presentation of the Concept to the Customer
The customer was involved in the project from the very beginning. He engaged the marketing department of the plant to evaluate the concepts.
In general, the customer liked both concepts, but suggested to make three amendments:
1. To make orders and claims statuses the same length.
Our solution: we preserved our variant and made the version with new statuses. We showed both variants to the client and gave arguments why our variant could solve the problem better. A user comprehends huge volumes of information easier, if to applies additionally the following:
colors – each status had its color that encouraged comprehension of information easily and quickly;
status name;
shapes – status length. This parameter encouraged user comprehension of information even quicker.
2. To highlight the section, where the user is, on the side menu with a bright accent color.
Our solution: we chose the color for the side menu, which allowed the accent color showing up advantageously and solving the problem.
3. To replace background at the authorization screen with the picture “House with colorful windows”.
Our solution: this photo was in absolute harmony with the project design concept. We found this picture at some photo-stock, bought it and used as a background for the authorization screen.
The photo is in absolute harmony with the project design concept
After the approval of the concept by customer we turned to design.
Working on the Program Design
We drew all the pages showing each element condition and created 380 pages.
We drew each element condition variant to consider all user scenarios with interface
Design Adaptation
Dealers find it significant to have access to the system from their smartphone or tablet, since they work “in the field”; they may have to apply to the system in a client’s apartment, roadside café or in the car.
It is time-consuming to develop additionally and maintain a mobile app. Besides, it requires additional expenditures. Thus, we decided to make an adaptive design. One which will have an access to CRM from PCs, mobile phones and tablets.
We have worked out all conditions on different resolutions
Screen size reduction is a “surgical” process. Each screen is worked out separately: information is arranged according to its importance rate, frequently used functions are moved higher, and some functions are hidden. Each project is developed individually. It is unwise to make one model for all administration panels, since each project has its own task and target.
Thousands of dealers work in the administration panel simultaneously. With this, there is a lot of information on pages, and it is required to arrange it in the way for all users to work comfortably and find necessary content quickly and intuitively.
We were thinking about users comfort in the first turn. When changing screen sizes data does not just contract, but adapt in the way for the significant information to remain visible
Presentation of Information
CRM is a tool for dealers and the main communication channel with the plant. A dealer can see all the information on his orders in the system: which production stage each of them is at, and when each order will be shipped. The dealer immediately receives information on status changes at partial or full order execution, shipment and delivery. Via CRM the dealer can make up financial reports, see photos and schemes of constructions, track delivery dates, and communicate with a plant’s manager.
Any dealer requires accurate and true data to plan his work. That is why all information synchronizes, and data updates regularly.
The dealer receives complete information on each order status: when an order was received, when brought into production, manufacture, shipment and delivery dates, voyage and contact details of a driver
Construction
Each construction is displayed as a separate block containing complete information on the order.
For the comfort of dealers all titles, descriptions and meanings in the system are displayed fully without shortenings
The dealer can see complete information on his order and payments within the “Finances” section. Delivery process is also fully visualized.
Dealers know exact funds circulation in terms of their orders
Load upon the Plant
After design approving we started preparing to programming. We started with high-level architecture. We forecasted potential load on the system and chose technical solutions.
The plant must work tirelessly and without mistakes, producing the best products and service for its customers. CRM is the way to ensure this happens.
We forecasted that our client’s business would grow. It means that instruments must have an opportunity to change and scale fast. That is why we paid special attention to the project’s architecture: server architecture was divided into separate services. Such architecture simplifies system support. Even if you return to the project in several months, you will quickly orient within it. In addition, it is easy to test the project, set and introduce new functional blocks.
Server architecture was divided into separate services, and service codes were made module and with weak interconnections between layers. This allows introducing new functional blocks maximum fast
Within the work course we made sure that the decision was correct. When “Ekipazh” opened its second plant in Khmelnytskyi, we on-lined it without any problems and additional investments.
We fix our solutions in requirements specifications. The team of programmers works on the basis of this document.
Programming Features
We create closed API to transmit data between system elements. By means of API methods data are received and entered into databases.
Data exchange and data actualization in databases is a background process. Thus, data transmission from the plant’s servers and their background entrance will be a potentially narrow place.
To find a solution and synchronize two teams we went to the plant for our solution presentation and its agreeing.
We consider all these details at making requirements specifications.
This is how requirements specifications for program realization look. RS contain everything up to the tiniest details.
Our main task is to create a system with high failure resistance. Two accounting systems and users are the sources of the system load.
To make failure resistance higher we used a contemporary stack of technologies. For this project we applied the queue server called Gearman, which provides the following:
Parallel process execution, which allows renewing data quickly.
Regulation of access to external resources.
Moreover, Gearman solves problems with parallel data processing and allows circumvent restrictions to memory limits of one PHP script.
We understood that line production status was changing 2-4 times a second and there were other background tasks producing server load. System load was nearly 2,500-3,500 inquiries a minute at blank cycle. It is not that much taking general number of server inquiries, but these are background inquiries, which mean a great possibility of failure at such a number. That is why our actions were directed to the decrease of a possibility for background system failure.
We used the queue server for that. It was accepting all inquiries during synchronization and confidently treating a bulk of order updates with its given productivity without creating overload on the server.
We on-lined a very detailed logistic system, which was blocking information updating in case of any error and simultaneously sending us an e-mail about system failure in the background.
We were working with developers from the plant very thoroughly. We conjointly accepted a comfortable format of data objects transmission, and agreed restrictions to avoid unexpected sending of data in an invalid format, and unintentional DDoS attacks during synchronization.
In addition, we decided to make the system available not less than 99.98%, which means the system downtime 4.01 minutes a week, 16.9 minutes a month and 3.38 hours a year. AWS servers had the same figures. It is important to understand that there is never a system with 100% availability. Any system even without problems will stand idle during server reboots, new releases or routine maintenance. We managed to reach this figure. Currently the system has been working in the “combat” mode for 4 months, and the figure was 99.99 at the moment of writing this article, which constitutes only 4.32 minutes of downtime a month.
We used Redis to speed up information delivery. This system makes the work on the project significantly faster due to operating from RW memory.
Brainstorms help us to find optimal solutions
Synchronization
CRM synchronizes with several plant programs: production (where the operational process takes place) and accounting with financial information. A team from the plant was responsible for synchronization being a very important stage. System operation accuracy depends on how accurately data are transmitted. Thus, synchronization requirements specifications, describing the process logic, were created.
For instance, data on the order page are gathered from several databases.
The work with accounting systems was the most complicated for us within the project. They had been built and developed over a longer period of time making it very difficult to change anything. We had to find a balance not to destroy the existing system. At the same time, the system we were creating didn’t depend on accounting systems. So, we had to add extra processes to the business logic of server application. They were de-normalizing obtained data objects and were recorded in the structure we could use with maximum efficiency. We spent a lot of time not to make additional processes our “anchor”.
This example shows which bases the data come from and how they appear on the page
Testing and Troubleshooting
In terms of development we followed SCRUM methodology. Project testing is divided into two parts: testing during programming (in sprints) and final system troubleshooting.
Final system troubleshooting was more extensive, because we wanted to make sure that the system would work smoothly during the “combat” mode. For example during testing, our test cases covered not only the newly implemented system, but also detected how the accounting system would behave in case of a new system failure. Will the error be accepted and synchronization continue with insignificant data loss or will it completely stop.
We performed the system load testing 5 times at the start, and each time we added +30% of productivity. We consider the obtained output result to be worth of all applied efforts, since we achieved the most important thing. The made instrument could solve problems and needs of the business without creating new ones.
Process of testing the system
A testing engineer, who was checking every executed function, participated in system development. Before testing we built up a testing plan and checklists to try methods.
Testing plan and checklists to try methods
We were checking each system element at the stage of final troubleshooting: API for synchronization, API for the web panel, administration panel, synchronization between CRM and bases of the plant. Besides we performed system load testing with border values.
After final troubleshooting we forwarded the project to the client to try it. System development together with testing took 11 months in total.
The customer is satisfied with the program. We can already see the first results: operation of the plant has become substantially faster, the potential for production growth with the same number of employees appeared. Dealers are pleased as well, because the work is performed under the unified standard, orders are not missed, and claims processing is fast.
So, the system is launched, and we are receiving feedback from users. Now it is time for mastering stage.
