Ten years ago, large retailers with extensive store networks saw online sales as a fashionable add-on to the real business. By 2016 this is no longer a nod to fashion but a strategic direction: if you are not online, you do not exist. The decision to "build our own internet platform" is the start of a long road, and it is one thing when a company with a modest turnover takes that road, having been geared towards online sales from the outset, and quite another when it is a traditional retailer whose business processes are built around offline.
This is exactly the kind of case we want to talk about: building an online store for the INTERTOP chain. It involved plenty of challenges: deliver quickly; bring the physical stores and the online platform together into a single space where customers have access to all the familiar options; carry the entire marketing toolkit over from offline to online without losing quality. But the main thing we want to discuss is the subtleties that always come up in global projects like this: how to build communication with the client, how to set development priorities, how to avoid building functionality that nobody ends up using, how to find the balance between business requirements and the limitations of the system.
The situation and the objective
INTERTOP is a large footwear chain with more than 200 stores in Ukraine and Kazakhstan. The chain has operated offline for a long time and with great success, building a large and loyal audience. Online, however, its presence until 2015 was limited to a showcase site that served mostly informational purposes: customer reviews, news, announcements of new promotions.
The site came with an online store attached, but with very limited functionality: a trimmed-down assortment, marketing promotions that did not extend to online products, and no way for shoppers to use discounts or bonuses. In other words, compared with the offline stores, the site generated almost no sales.
Let us unpack that a little. For the online platform to become an independent channel, it has to be fully integrated with the company's ERP system. To make individual offers to customers and give them discounts and bonuses, integration with the CRM system is required, so that the entire history of the relationship with the customer is available online: when they made purchases and what they bought, how many bonus points they have accumulated, which promotions they have used, and so on. A single information space means that the chain's customers stop seeing any difference between the ways they interact with INTERTOP: trying on boots in a real store, for example, and right there, from their phone, ordering them delivered to another city.
Priorities: what went into the first release
Development is a multitask process and a long one, so effective work depends on setting the right priorities. Right means setting them so that the client's fundamental business problems are solved in the very first release and they can put the platform to the test in real working conditions.
Task No. 1. Full integration of ERP and CRM with the online store
Synchronisation of stock levels, orders, user data, and bonuses earned and spent. An enterprise CMS was chosen as the platform for the online store: it has an open architecture and fairly broad built-in capabilities, and a certain flexibility in the system gives the freedom to implement the non-standard functionality the client needs. The priorities here were as follows:
- full integration with the internal accounting system (the entire 20,000-item assortment was pulled into the online store);
- filling the site with content — here we worked together with the client, since in the fashion industry the highest-quality content is the main factor influencing the purchase decision. It was important to publish descriptions and good photographs for the whole assortment: we started with three photographs per product, and now there can be up to ten;
- the ability to find and choose a product by brand, colour and size (for the time being without comparison against others or availability checks);
- refining and simplifying the ordering procedure;
- launching in two languages at once: Ukrainian and Russian;
- the ability to use the familiar bonus programmes online (all user data was pulled into the online store);
- removing duplicate user records and linking bonus cards.
What matters at this stage?
On the client's side
An understanding that there are no magic platforms: whichever one you take, it will need customisation and then support. And fast feedback: employees start working with the system and can tell you straight away what has been implemented conveniently, what has not, and what needs fixing. It is important not to keep quiet about problems or put them off until later.
On the developer's side
Do not build all the required functionality at once and do not disappear into the project for six months just to produce some kind of result. Define the minimum viable functionality together with the client, launch the first working release as quickly as possible, and then refine it, tuning business processes against real working situations.
Because we did not spread ourselves thin and concentrated in the first stage on integrating the assortment and the user data, the very first release was able to give those customers who had previously bought only in offline stores using bonuses and discounts the ability to visit the site and link their account to their bonus card so they could use it online as well. Users kept their purchase history, could register new points and spend the ones they had already accumulated — in other words, what they could do in the online store became exactly the same as offline, and in some respects broader.
A simple indicator that the functionality was implemented well: in the store's very first month of operation 25% of purchases were made using the INTERTOP PLUS bonus card, which customers registered in their personal account.
On the subject of focus and of not being able to do everything at once: in the personal account we invited the customer to give us additional information about themselves, for example the birthdays of family members, and rewarded them with bonus points for it. Yet it was only in the second release that we made those points land on the card immediately so the person could spend them; in the first release there were more important tasks, and the points were merely accrued.
Delivery and acquiring: integration with Nova Poshta
Task No. 2
Integration with acquiring and the Nova Poshta delivery service: automatic linking to post office branch addresses and the ability to place an order regardless of the state of the delivery service's servers.
To simplify product delivery, we agreed with Nova Poshta on data synchronisation so that customers could link their accounts to a particular branch. But there is always a risk in interacting with external databases. First, a postal company is not a static system: branches open and close, and at some point a customer may discover that their branch is gone or that the address has changed. Second, its servers may be unavailable, which means there is no way to promptly refresh the list of branches on our site, and now it is our customer who gets stuck at the checkout stage because their branch will not load. So all these risks have to be taken into account in development, with the system configured so that the checkout stage works under any conditions.

This example, incidentally, is an interesting way into the dilemma of balancing automation against manual work. When several hundred orders come in during a day and operators have to switch between systems constantly, the risk of a mechanical error grows many times over. So we extended the functionality through the API so that the waybill number is assigned automatically. Automating this operation saves hundreds of minutes of operator time and reduces the likelihood of error.
On the other hand, there are always plenty of subtleties in how addresses are written: a user may accidentally use Latin letters, enter the address as "Kyiv, Pushkina-1" instead of "Pushkina, building 1", and so on. Forcing them to fill in a multitude of fields until every one of them is filled in correctly is inconvenient for the customer. Trying to anticipate every possible way of writing an address and account for them all in development is expensive and ineffective. In the end we arrived at a compromise: the user enters the address in whatever way is convenient for them, and then the manager in the admin panel sorts that address into the dedicated fields. This solution closed off almost all the complaints about waybills.
Marketing that does not come out of the box
Task No. 3. Partial implementation of marketing tools the platform does not provide for
The chosen CMS is an excellent system for solving typical problems, and its components are reliable and tested on hundreds of projects. But when a company has enormous marketing experience of its own and its own accumulated practices, off-the-shelf solutions do not save the day — they have to be extended.
Take the presentation of the assortment, for example. Everyone knows that certain merchandising rules apply when products are laid out on store shelves, but online those rules are stricter still. The order in which products are shown to a site visitor depends on a dozen different factors: seasonality, current promotions, the state of the warehouses, the availability of SKUs, and so on. For the INTERTOP platform we made it so that new arrivals are shown first, then the seasonal collection, the previous collection, products temporarily out of stock, and products that have been unavailable for a long time. Today a manager can go into the admin panel and specify any season that should appear at the top. For example, when summer footwear is selling actively, you can deliberately push something from a different part of the assortment to the top and, riding that wave of demand, sell some moccasins as well. This is a business decision taken as the situation demands, so manual control is provided here rather than automatic.

In work like this there are always many details that are "minor" in terms of development but important from a business point of view. Another example: products that were once on sale but whose supply has stopped and will not resume are made accessible via direct entry from search engines. Shoppers cannot see them, of course, and they are absent from the catalogue, but it is important to keep them on the site in order to preserve search traffic. Or here is another example of non-standard functionality — handling a category such as "Not available in city X". We make such products semi-transparent and drop them to the end of the catalogue regardless of the season. This also has a positive effect on how the site is indexed by search engines.
Discounts and promotions
INTERTOP runs a very active marketing policy. Up to 20 promotions may be running at the same time, to the point where the managers themselves can lose track of which promotions a given product falls under and how discounts should correctly be applied to it. So the first thing that had to be done was to extend the standard CMS functionality, which does not allow you to define special rules for handling the cart and calculating discounts.
The company has 4 types of discount:
- bonus points;
- gift coupons;
- a 5% discount for paying by card;
- an individual discount on a product.
The problem was that all 4 discounts were applied simultaneously and the final price came out incorrect. The algorithms had to be changed so that they were calculated in a particular sequence: first the product discount is applied, then the coupon is redeemed, then the bonuses and the 5%.
Customisation was needed for almost all the popular marketing promotions — for example, for the "Buy 3 pairs with 30% — 50% — 70% off (the third is the cheapest!)" promotion, or the "Second price" promotion, where the regular price for a product is shown first and then the second, promotional price. All promotional prices are calculated in the company's ERP system and have to be displayed correctly on the online platform.
The "Buy 2 specific footwear models and get a gift from the new collection for UAH 1" promotion, however, did not work online. This is a good example of the fact that not every tool that is effective in real stores can be carried over to the online channel.
Gaming the bonuses
A live issue for many stores. While a promotion is running, the number of bonuses a customer can earn is at its maximum. If you let them be spent straight away, the bonuses cut the selling price of the product considerably, and are then accrued again on the increased base. In the end we found a wise compromise: the actual crediting of bonuses to the card was moved to a short delay after a promotional purchase is made. The ground for gaming the system disappeared.
The "Check availability in offline stores" feature
This is a very useful thing for creating a single information space within the company. It required extending the integration with warehouse data, because a check like this means regularly exporting stock levels for EVERY physical store. But the effect on the business was visible immediately: sales rose once users stopped wasting time on products that were not available anywhere near them. And from there the work on full omnichannel began, so that the customer could obtain a product that is not nearby at the moment, and obtain it where they need it.
Omnichannel and the moment of transition
Omnichannel is probably the hottest trend in e-commerce. Every second online store declares that it is moving towards omnichannel. What is it? The prefix "omni" translates as "present everywhere". In practice it means the following:
- the store or chain is equally well represented both offline and online — the same prices, level of service, promotions and assortment;
- online, the store is equally well represented on any device: laptop, tablet, smartphone;
- the shopper gets the same experience when visiting the online version and when visiting a physical store.
In essence, omnichannel means absolute freedom and convenience for the user: which channel to use to interact with the seller, where to buy and where to collect the product, and how to use their discounts and bonuses. For example, from a store in Odesa you can arrange delivery of your chosen pair of shoes to Dnipropetrovsk, where the customer will pick it up within an agreed timeframe; you can reserve a particular pair at a specific store and buy it later. As practice showed, around 40% of online orders are reservations and pickups. It came as a surprise both to us and to the client — another example of how online differs from offline. It turns out that people find it convenient to grab their purchase from a store on their way somewhere.
It is important to watch users and to base all customisation on their behaviour. People do not separate channels! For them, an order on the site and a visit to a real store are all INTERTOP. And we, too, have to remove the differences and make sure they operate under the same rules.
Here is how the ordering process is implemented, for example: the user selects on the site the city they are in. Based on their location, they are shown products with up-to-date stock levels for each size. During the purchase they can choose the "Delivery to store" option and specify any store in any city. The footwear is delivered from the online store's warehouse, and if the required pair is already in the chosen store, the reservation is created automatically. This service is free of charge.Oleksii Sapunkov, project manager on the INTERTOP side
The reservation process is accompanied by SMS reminders. This is an important psychological point: the shopper hesitates to the very end over whether to take it or not, even once the order has been placed. Continuous SMS support is psychological help for the customer in completing the purchase. After SMS was introduced, the share of abandoned reservations fell. Via SMS we remind them where their footwear is waiting, how much time is left before the reservation is released, and so on. And now we are also adding the ability to adjust the SMS text so that each shopper can be sent a personal message.
The moment of transition
For a large chain, moving online is critical in terms of maintaining the level of service and the brand image the customer is used to. That is why the task here has two steps.
- Do not lose customers. For this, users who log in to the online platform need to be able to use all the same options as in the real store they are used to.
- Make it convenient for them. Online there is every opportunity to do so: convenient product selection, delivery from wherever the item is in stock to wherever the customer needs it, and a personalised approach.
Thanks to these steps, in just 3 months INTERTOP gained a large loyal audience online.
The fine points and subtleties of the active phase
It is impossible to describe everything that was done over an eighteen-month project. But we can draw attention to the things that matter, so that your own communication with developers is productive.
Debatable functionality
It exists in every project: the client proposes bolting on one more flourish here, while the developer reckons that this flourish will not bring the client any more shoppers; the developer proposes polishing up this particular feature because the system will then run faster, while the client works out what it will cost and weighs up whether they really need that speed.
In our project, most of the questions connected with the administrative section turned out to be functionality of this kind. INTERTOP's managers started from the following premise: our call centre staff are not programmers, so let us make the interface as simple as possible, so that nobody has to think or work things out in the admin panel. You need to perform an action — you press a button — you get a result. At first there were attempts to adjust the look of the admin panel based on spontaneous feedback from managers along these lines: a person runs into a problem and, without establishing whether the functionality really is inconvenient or whether they simply did not work out how to use it, writes a complaint, the complaint travels around the managers and after a while comes down to us in the form of a technical specification.
So our first task became finding consensus with the client on two questions:
- how to structure the process so that the problems employees encounter turn into development tasks not spontaneously, but with an assessment of their weight and significance for the business;
- how to find the balance between the necessary degree of automation and manual work in the admin panel.
There is always a line up to which automation brings benefit and simplifies business processes. But beyond that line lies unjustified inflation of development costs and increased complexity in the integration between the ERP system and the online platform. That line is well illustrated by the waybill example: it is simpler for an employee to edit the address the customer entered and put the information into the right fields (10 seconds) than for the customer to fill in a form with a multitude of fields and for the developer to complicate the development process and make the platform expensive to support.
Unused functionality
Another characteristic phenomenon is maximalism in the requirements during the early stages of development. You want everything and you want it now. This is the most common way functionality that later goes unused comes into being. Over time it is replaced by a sensible compromise between the needs of the business and technological constraints. The compromise is reached more easily if decisions about implementing or reworking functionality are taken by the business units alone. Every day they track the patterns: what users make active use of, where they get stuck, where they leave from, and so on. If a change is proposed on the basis of such analysis, the chances of it not being needed in the future are minimal.
Peak loads
In e-commerce, the system's ability to withstand peak loads is critically important, when on promotion days and during seasonal sales 200—500% more shoppers arrive at the site than usual. The solution's architecture is hard to test for such a situation under everyday load.
The INTERTOP platform uses a cluster architecture, with the load distributed across several servers by a balancing algorithm. On the one hand, this makes both the system itself and its operation more complex; on the other, it is simply the price worth paying for the system to run without failures on the busiest sales days, with a large influx of shoppers. At the same time, the managers' work in the administrative part of the platform must always be stable regardless of the overall load, so their section is hosted on a separate server.
The architecture is tested with synthetic tests, where the history of on-site actions of 50—100 typical visitors is taken, these scenarios are run in several thousand threads and the load is measured. In parallel, organic tests are carried out: the history of all visitors' actions during peak loads that have already occurred is analysed statistically. This is how you identify the parts of the system that are used most often but perform most slowly. Other potentially problematic areas are those that are not called more often and do not perform more slowly than the rest, but for whose functionality the ratio of calls to delays is critical.
Monitoring the system's behaviour under peak load quickly reveals the weak spots. What is more, problems can be caused by both technical and organisational factors. For example, we noticed that because of the large number of visitors the time it took to generate a single page grew to 3 seconds. Analysis of the causes showed that products must not be repriced while promotions are running, because of the mass cache flushes it triggers. This is an organisational matter, which the client resolved by issuing special instructions to the managers.
Our mistake
No project is without one. In this project, for instance, we did not think through at the outset how best to implement the version of the site for mobile devices: build a responsive layout, a mobile version of the site, or develop an app. There is no point building a mobile app straight after launch, so we took the route of a mobile site version — displaying the content in a separately developed template. The functionality the client wanted and the design mock-ups coming in from the designers did not suit the responsive principle. We followed the lead of the client and the designers and began work on a mobile version of the site. Naturally, every change made on the site had to be made twice — for the mobile version as well. After struggling for several months, we did convince the client that the design had to be reworked as responsive. That is the more expensive option in development, but it is a one-off investment, unlike a mobile version. We should, without question, have done this straight away and insisted on the right decision.
Communication with the client, and documentation
The foundation and backbone of any project. If we do not want the project to grind to a halt at the very first stage, ALL processes, ideas and discussions have to be structured and documented. From the very beginning, all development business processes are entered into the project management system. New releases are planned well in advance and ship on a firm schedule. Between releases, only critical changes (errors, breakages) are allowed, and these are made as hot fixes.
There are 4 types of task in the project management system:
| Task type | What it means |
|---|---|
| Green | Everything is agreed, the technical requirements are approved, the task can be taken into work |
| Yellow | We are recommending some change to the client: we understand why it is needed, we write up the rationale and wait for the client to look at our proposal and make a decision |
| Orange | Bugs that have been found and need fixing, or minor technical refinements to global tasks that are already complete |
| Red | New, as yet unformalised requests from the client (a new marketing attribute, for example) for which there are no details at all |

This chart clearly shows how the number of change and refinement requests grew avalanche-like after launch (the red line). We could not keep up with them, and the green line shows how far behind we were on the time it took to deliver a request. Gradually, however, the work settles into shape, and after roughly 160 days we started closing tasks at the same rate at which they arose.
From the developers' side, the ideas put forward are mostly about "related improvements": to make several promising changes easier to implement, let us build in groundwork for the future in the shape of this and that. For example, we proposed extending the geo parameter for the "Product availability in the retail network" filter so that a visitor's geolocation is taken into account as they browse the catalogue and only the products available to them are shown right away. As Google Analytics shows, this function is in active use.
On the client's side, the majority of requests come from business units, particularly marketing and sales. That is natural. How the client's IT department behaves in this communication matters a great deal, because it is the IT department that should serve as the primary filter for the business's requests.
With INTERTOP's IT department we spoke the same language. Our colleagues there are professionals with a great deal of experience. This was especially noticeable at the first-release stage, when a certain amount of chaos reigns, a lot of contradictory requirements and requests come in from the business, and they have to be filtered very carefully so as not to spread yourself thin and to deliver a result within the agreed timeframe. All the more so in our project, where in three months, including the first introductory meeting, we effectively built the plane in mid-flight. And we tried not merely to build it, but to do the work in such a way that afterwards we would only be refining and developing it, not fixing it.Kostiantyn Perepechaienko, project manager on the ANIART side
User documentation
389 pages of user documentation were written for the INTERTOP platform. It gives a general picture of the system when any changes are being planned, and it makes it easy to bring a new developer into the project. For store managers and call centre staff, the documentation is their user manual. Any change to the system is documented, and all users receive notifications about the pages and sections that have changed. The documentation has a collaboration system: managers can ask for a process to be described in more detail or supplemented with additional screenshots.
Testers are the best at documenting and describing usage scenarios — they check the functionality many times over, know a great many subtleties and produce the highest-quality instructions. In parallel, technical documentation is maintained for the system administrators covering maintenance, backups and security. For them the FAQ section turned out to be very important, setting out as simply as possible both what to do in critical situations and their day-to-day duties.
Client vs developer: degree of involvement
As with anything: if you want a quality result, immerse yourself in the work alongside your contractor.
- Take part in development from stage 0. No detailed technical specification can contain every subtlety. You need to check in at every step, and for that the client's representatives have to understand what stage of development we are at and where we are heading, and to adjust tasks in good time if changed business conditions require it.
- Restructure processes internally. It is better to formulate KPIs straight away — it encourages managers to get to grips with the substance of the processes from the very start, because online everything works differently: marketing, logistics, customer service. When planning a sale, for example, you have to understand that an order can be placed by someone from any corner of the country, so products must be distributed accordingly across the logistics points; it is important to coordinate online and offline promotions with each other so that situations with products missing from the warehouse do not arise.
- Restructure the process of communicating with customers. The online environment is different! You cannot carry processes over from offline to online as they are. It is for the shopper that we try to make the new environment resemble the familiar one. The company itself and its employees have to understand clearly how online differs from offline, learn to work in the new environment and adapt their processes to it. In a real store, any slip by a salesperson can be smoothed over with human contact and attention. Online this is practically impossible: if a person does not like something, they will not try to work it out — they will close your site and go to another one. In a real store a visitor is ALREADY practically a customer, especially if they have tried the footwear on, picked up the box and headed for the till. Online they can drop out at any moment, especially if ordering, payment and delivery are spread out in time. To avoid losing the customer, that time has to be cut as short as possible or filled with something — remember the story about SMS support?
How to launch an e-commerce platform quickly and at the lowest cost
- Set priorities: split the functionality into core and additional, and include in the first release only what the platform cannot operate without.
- Ship the first release of the platform as quickly as possible and refine it based on real feedback.
- Look for a sensible balance between the degree of automation and manual work — this is how you avoid inflating costs and dragging out development timelines.
- Implement marketing promotions online with exactly the same mechanics they have offline: the shopper should see that in this new channel all the promotions work the way they are used to.
- Set up a communication system from the outset: the history of every change to the platform must be traceable, and everyone involved in the project must be able to see task statuses and exchange information.
- Classify incoming requests correctly and from the outset, so as to separate isolated cases from improvements that will genuinely benefit the whole system.
Results
INTERTOP is the largest footwear retailer and the undisputed market leader, with more than 200 stores in Ukraine and Kazakhstan. The chain has operated since 1994 and is known for quality footwear from the world's leading brands and for its active work with its audience, so any marketing promotion it runs draws an enthusiastic response from shoppers and a serious jump in sales. A year after the site was relaunched and multichannel sales began:
ANIART specialises in developing large projects in e-commerce and in enterprise solutions. We have earned a reputation for being able to do in a month what others do in three, for building systems capable of reliably processing millions of transactions, and for supporting all our projects properly. Over the course of this project:
The active development phase involved 7 people; a year later 2 people remained in development and 3 in support. Procedures were established for planning and formulating tasks, for monitoring delivery deadlines, and for testing and server monitoring.
This is not just a new sales channel but deeply considered modern functionality. It is a step into the future of retail — omnichannel. Where online sales once existed on their own, they now work hand in hand with the offline stores.
