From a client’s perspective, the launch of a webshop development project starts by asking questions and finding the right direction. Once a few things are settled, we begin seeking professional advice and we start asking for quotes and offers, which may not be as easy as it sounds. Deciding on the appropriate framework and choosing the right company to work with requires quite a bit of time and a whole lot of diligence. If we don’t put enough effort into these steps and we don’t ask for the right quotes, we might end up making our own work harder than it has to be. 

This is why we should kick things off by creating a proper brief or more preferably, a detailed and in-depth business specification ahead of sending out requests for quotes. 

• By doing so, we’ll save time for ourselves in the first hand. If the developer company is not being supplied with enough information about the project, they will start asking all the questions themselves, elongating the process. 
  
• On the other hand, once the quotes and offers start coming in, we will be able to match these up against each other, as they will be created for the exact same technical scope of work but by different companies. 
  

The business specification in this case, is a type of document that clearly explains the details of the product (webshop, site, software, etc.) and it lists all the needs and the expectations of the development as well.

We can start reaching out, asking for quotes with this document – also known as a business requirements document (BRD). Without this we won’t be able to compare the offers or carry out the tendering process. We also wouldn’t be able to figure out how complex the development would be, how long it would last, and how much it would cost. Using a one or two-pager that’s been put together poorly could result in getting offers that might differ greatly – financially speaking, discrepancies might be in the millions. On a similar note, without the right document we might not be able to find the most suitable supplier either. 

In this article, we will help to identify a few questions that need to be asked, a few major points of consideration, and last but not least all the important details that need to be put in writing ahead of kicking things off. As we work mainly on Magento-based developments, we will focus on this platform but the majority of the things outlined below will be just as relevant for other webshop technologies as well. Let’s get into it!

General business information

In our BRD, we should include all indicators that will help the developer companies to evaluate the intensity of our e-commerce activity and our estimated traffic so that they can put together relevant offers. If we ask ourselves the below questions first, we will be able to choose the most suitable alternative.

• What traffic are we expecting? How many unique visitors do we have on an average day and how many to expect during a campaign period?
  
• How many page-loads are expected to be generated by visitors?
  
• How many sales are we expecting to make in our webshop on a regular day?
  
• What’s the average basket value to expect? The higher this value is, the more important it is to focus on tools that boost additional selling.
  

Our quote request for launching a webshop development should also contain the below information:

• How many languages will be available on the site? If multilingual options will be available, what are the exact options to choose from?
  
• If multiple languages will be available, how can they be selected? (Manually or by geolocating?)
  
• Does the website need to manage different currencies? If so, which ones are these? Would we prefer to calculate the different prices based on currency exchange, or would we rather set the individual prices for each product by using different currency values? 
  
• Do we need more shops and shop views within the same installation? In other words, do we need to have different sites with the same or similar functionalities, with different designs and different URLs run on the same webshop system and the same admin panel? If we do, what’s the correlation between these sites?
  
• Is there an offline store or store chain behind the webshop? If there is, how do they receive stock, and what’s the relationship between the store(s), the supplier, and the webshop? How are orders managed? Are they being fulfilled by the store(s) or does the webshop have its own dedicated warehouse?
  
• On top of the above, it’s useful to detail the concept and the business goals of our future webshop and it’s worth sharing all details that might be important for the developer company to know.

Product info and product relations

The foundation of a webshop lies in the products that will be sold on it. Here are a few questions to add into your brief:

• What’s the estimated amount of featured products and roughly how often will the offering be updated?
  
• How will the product information be uploaded? (Would it be done through integration processes, via an admin panel or maybe both?)
  
• What types of products would we want to feature besides simple products? (Such as configurable products, product batches, or product groupings?)
  
• Will sets be available – sets, as in curated selections of products that will be managed as a single item. If so, would these have their own product IDs?
  
• What kind of product descriptions should be available and how long should these be?
  
• Do the products have technical parameters that we would like to showcase in an interactive way?
  
• Would we like to show similar items on the product page?
  
• Do we need to organize the products into categories only or should they be grouped into brands as well?
  
• Should we show upsell products to the customers in their baskets?
  
• Are we going to feature downloadable leaflets, brochures, or other kinds of documents for the products?
  
• Would we like the users to be able to rate the products and leave comments?
  
• Would we like the customers to see what products they have checked already, as they are browsing through the main pages of the site?
  
• Is there a need for a comparison feature? Are we going to have all the information that we will need in order to be available to compare products?
  

Payment options

Customers will have to pay for their purchases at the end of their journey: to make this happen, we can choose from a wide range of different payment method options. When putting our brief together, it’s recommended to have a think about the payment options that we would like to offer to our customers. A few examples including, but not limited to the below:

• We will most likely need integrated card payment options. Most local and international banks offer such solutions – in Hungary, OTP, and K&H Bank are the frontrunners within their field. 
  
• Card payments can also be made by adding a payment gateway into the process, such as Braintree.
  
• Think about the possibilities of COD alternatives (cash on delivery)
  
• Many webshops offer advanced payment solutions as well. 
  
• You might want to consider adding PayPal in as an option for example.
  

Delivery options

The purchased items have to reach the customer in one way or another after their order has been placed – this is called delivery or shipping. When putting our brief together, it’s important to have a few of these options defined and to think about the different ways of how we want to send the products to the customers. See a few possibilities for this below:

• Which courier company will manage deliveries?
  
• Would the data of the placed orders reach the delivery partner’s system automatically or do these need to be handled manually. 
  
• Would we offer extra services with additional fees (such as express delivery)?
  
• Would we like to offer a pick-up option? (Local options include Pick Pack points, Postapont and Foxpost) 
  
• Would we like to offer a personal pick up in one of our stores or at our registered address?
  
• Think about the possibilities of offering free shipping above a certain order value and also think about how the delivery prices are defined (does it depend on the volume of the purchase, the delivery location, or maybe on the weight of the order).
  
• Are we going to offer international shipping? If yes, how is this going to alter the offered delivery options and delivery costs? Are the delivery times unified – or does it depend on the product type or stock availability?

Price management

Another important aspect to consider is the way prices are managed in our webshop. If it’s not clarified in advance, these are the usual questions we would ask our clients:

• How will the prices be set? By using manual methods via the webshop’s admin panel, by importing them or by means of integration/data synchronization? 
  
• Is there only one price per product or can several different prices be added to one item?
  
• Besides showing the price of the product, would we also want to show the unit price? 
  
• Is there only one tax rate available or can gross prices be displayed based on different VAT rates?
  
• Would all customers see the same prices? Or would we have segmented groups that would see different, let’s say promotional prices? Are there any product categories that only certain customer groups can have access to? 
  
• What pricing rules will we apply? (Unique sale / promotional price, catalogue price rules, basket price rules, vouchers that can be redeemed in the basket or at checkout.)
  

Stock management

Stock management for a webshop is always one of the most important aspects of development projects. Inventories are heavily influencing conversion and they have an effect on sales as well. Magento is equipped with advanced stock management functionalities, on which unique business models can be built. Think about the below things:

• Do we have a separate stock, designated to online sales, or are we selling the items of offline stores – or, is it maybe a combination of the two?
  
• How is inventory being uploaded to the webshop?
  
• How often does the stock change?
  
• Should items be out of stock to be removed from the frontend or can they just appear to be unshoppable? 
  
• What kind of stock conditions are we dealing with? How are the delivery times, the shipping prices and the payment methods correlate to these? 
  
• How and where do stock information appear and how much do we want to focus on these. 
  
• Would we like to add filters, organizational and navigational tools to the stock attributes?
  

Invoicing and logistics

Since the Hungarian legal regulations do not allow invoices to be generated directly in webshops, we will most likely need to integrate our site with an accredited invoicing software (or an ERP, but we will discuss this a bit further down the line). Think about the logistics behind the invoicing process – how should the order information be forwarded on? If you wish to use an external software (such as a stock management system) for the logistics, then mention this in your overview as well. 

Ergonomics and best practices in functionality

The success of an online product does not simply lie in one good concept or idea.

There is a whole lot more to it: from a rich set of functionalities, through appearance and functioning all the way to the services being offered. There are hundreds of small, but creative innovations and solutions that will take the site to the next level. Ahead of launching a webshop development project, there are a few things we should do first. Defining our own expectations is a great thing, to begin with, but carrying out market research and seeing how our future competitors are doing locally and internationally is just as important, besides gathering ideas and looking into future possibilities. Kicking off a project should contain our own, specific ideas but great examples should be added in too when and where possible. Gather these and add them to your document.    

Questions around ERP integration

The offer we’re requesting – and the project’s technical complexity – heavily relies on our plans around integration: would we like to link it up with our ERP system straight away or do we have any intentions to do so in the near future? ERP integration is one of the most important aspects of an e-commerce development project. If the need is there, it will end up being one of the most important processes that will also require the most thorough technical planning before and along the way. 

Listing out a few of the potential demands, that defy a complex e-commerce development project will put this into more context: integration processes include the real-time syncing of constantly changing stock levels, sharing of order information to an ERP, showcasing ERP-generated product information in the webshop as well as aggregating the product information of the available products both in-store(s) and in the webshop. In certain cases, setting up the integration processes alone might cost more than developing a webshop itself.

Let’s not forget that creating the right ways of working ultimately defies the success of our business operations. 

Let’s look into the details of the integration processes between a webshop and an ERP in a bit more detail. Have a think of these points and once you distilled your vision, make sure you share this with your future partner, working on your development project:

Product enrichment: from an ERP to the webshop

Despite the fact that Magento is a great product management software on its own in certain cases, the important product attributes and data might be secured somewhere else: in such cases, the data is being processed in an ERP and it’s then forwarded onto the webshop. In other words, the product is created by the ERP and is then uploaded to the webshop via a partial integration process. 

In certain cases, product enrichment carried out through an ERP might not be fully comprehensive. This means that new products will appear being inactive in the webshop due to missing product attributes. The additional information needs to be added manually in the admin panel by the editors – this is where the products will also be categorized, enriched with their unique product descriptions, and with additional product assets such as images. In a similar way, the status of a product can also be managed by the ERP – such as the product appearing to be active or inactive in the webshops, based on its product id. 

If we are in need of a product enrichment process to be put in place, it’s important to mention what kind of data we are managing in ERP when we’re creating our brief. How is the data being added into the webshop and what attributes will be managed in the webshop itself? You can find out more about some of the data packages, that might come from an ERP below: 

• Basic product data (name, product id, short description)
  
• Product attributes and category information
  
• Product price, potentially linked price listings and VAT rates
  
• Status information and visibility
  
• Product images and other marketing or communication assets
  

Updating stock information between an ERP and a webshop

Both Magento and ERP systems do manage stock and inventory. When we integrate these processes though, we need to make a decision about where data should be handled (including the processes around managing, receiving, and administrating the current volume of the offering). In most cases these tasks are handled by the ERP – but all information needs to be up-to-date and available for the webshop as well. 

There are many ways to sync stock but the technical realization of these always depends on the frequency of data update cycles. The question is, how would we like to update the stock information in our webshop.

• This could be done through triggers: if the stock level has fallen below the threshold in the ERP, an instant notification is being sent to the webshop.
  
• In short, periodic cycles (every 5, 10, or 15 minutes for example).
  
• Or less frequently, by doing synchronization on a larger scale (such as synching once or twice a day)

The more frequent and intense the stock update synching process is, the heavier the load on the site – in such cases integrating a middleware software could be a good idea as this can resolve any issues around this. Try to be as clear about our stock management and business operational expectations as possible in our specification: these are both keys for any possible integrational developments and might make huge differences in pricing.

Forwarding orders

If we have an existing ERP, it’s very likely that we would want to integrate this with our webshop to process the orders that replaced (at least it’s very unusual not wanting to do so). The webshop’s orders are typically processed in the ERP (such as invoicing, generating the order confirmation letter, reducing stock levels, etc). This is done through an event-driven process – the event in this case meaning the placement of an order, which we would need to see immediately in the webshop. We should provide clarity on these events and triggers, the types of data we need when processing an order and if we can identify the data formats that are being used in the ERP that’s of tremendous help too. A few examples below:

• Processing customer data (data entered upon registration for example)
  
• Processing addresses (billing and delivery addresses)
  
• Handling payment and delivery preferences
  
• Details of the order that need processing (it is preferred to provide clarification on this)
  
• Processing additional data such as notes attached to orders, promotion fields, basket offers and vouchers
  

The two-way processing of the order status

Once an order is placed, a few additional actions take place in the ERP: the order is processed, it’s invoiced for, it’s handed over to the delivery partner, it’s completed, it’s canceled and so forth. During this time a few online documents might be generated – such as the invoice or the delivery note – which we might want to forward onto the webshop. It’s important to decide whether we want to do this – so that the user can get updates in their accounts or via automated emails. The synchronization of order status information between the webshop and the ERP, the processing of these, and the additional workflows around status changes are all important aspects of the integration requirements. Think about these in-depth and explain our expectations in our business requirement document (BRD). 

Managing users across the different systems

When a visitor signs up to the website and places an order, they become users with their own individual accounts. We need to make a few decisions here: would we like to share the customer data registered through the webshop with the ERP – or the other way around: do we have already existing customer data (such as loyal customer statuses) that we would want to extract from the EPR and upload to the webshop itself. Do we have any B2B partners who are featured in the ERP – can they carry out any special actions in the webshop? Do we have any registered customers, who can access special, curated, or exclusive information or product offerings – do these have anything to do with ERP processes? The list goes on and on… Reflect on these questions and think about the customer data flow between the two systems. Once we have some clarity, make sure to add these processes into our brief.

Integration Do you think you should integrate? Let’s have a go!

Closing thoughts

Now that we managed to go through this long list, we can see that asking for a quote, receiving and then processing these is a time-consuming task that requires sharing a whole lot of information as well as some in-depth thinking. Based on this we can come to the conclusion, that any development company that sends an offer to us without having all the necessary information they need is irresponsible and are very likely to be incompetent too. 

As a client, it is our own interest to receive offers that are based on detailed and extensive information – otherwise we can come across very unpleasant surprises and unexpected extra costs during the development project. Take these things seriously, be precise, and defy your requirements up to your best knowledge to be able to see the big picture. 

Previous works