Preparing eCommerce project documentation regarding functionalities before talking with an implementation agency is a crucial step that can save time, reduce the risk of misunderstandings, and lower project costs. With a well-developed specification, businesses can prepare better to evaluate offers, understand the differences between technologies, and, most importantly, ensure a more accurate cost estimate.

Every agency, regardless of whether they work on a Time and Materials (T&M) or Fixed Price model, estimates eCommerce functionalities based on project documentation. This documentation can be either provided by the client or created internally by the agency based on conversations with the client.

The main cost of the project is determined by the functionalities required for the project. The number and complexity of these functionalities (as well as the technology chosen for the project) will directly influence the implementation cost.

As clients, we are not obligated to create this documentation – a professional eCommerce agency should go through this process after properly qualifying the client. However, preparing for discussions with the agency based on precise and clear documentation offers many benefits that significantly facilitate negotiations, help in receiving suited offers, and allow for more accurate comparisons of technologies.

Quick jump

Benefits of preparing eCommerce project documentation by the client

  • An eCommerce agencies excel in the technologies they implement, but they may not necessarily be experts in your specific business domain. The biggest obstacle during discussions is balancing knowledge between parties: the client, who understands how the technology works, and the agency, which understands how the client’s business operates. By preparing documentation and listing all requirements on paper, you significantly improve this process for the agency and ensure that your needs will be better understood and reflected in the project estimation.
  • The technologies the clients compare often significantly differ in how they implement specific functionalities. For example, in one technology, implementing a feature might take 60 hours; in another, a ready-made plugin might be available; and in a third, implementing the functionality in full might not be possible. Therefore, having well-prepared project documentation and a cost estimate based on it will enable you to better compare different technologies.
  • Depending on the client’s purchasing strategy, preparing documentation will save them time in lengthy meetings and in explaining to the agency how everything should work. Some companies even send briefs to multiple agencies, asking for preliminary project estimates, and then only meet with selected agencies.
  • A less obvious benefit is that the client can better organize his own thoughts about what he/she needs. Agencies often encounter situations where even initial project requirements are not well-defined in the buyer’s mind. In many cases, early internal team discussions and establishing a preliminary version of functionalities and platform operations will help in better specifying the project’s needs.

Now that we understand the importance of creating initial project documentation let’s move on to how we should approach its creation.

Disclaimer
For the purpose of this article, we will focus only on greenfield projects. Greenfield projects are those where we build something from scratch. For example, a company that has only been selling its products in physical stores now wants to start selling online by building an eCommerce platform. These projects offer the opportunity to create a new digital presence without the constraints of existing systems or processes.

Organizations already operating in eCommerce and have built up know-how typically understand why they want to change their eCommerce technology. They know what works poorly and what works well in their current setup. Therefore, agencies rarely encounter situations where companies migrating their eCommerce platforms don’t have prepared documentation for the new project.

Additionally, this article only describes the correct way to present your business assumptions without detailing the process itself – that is, how to determine from a business perspective which functionalities are needed in the project.

How do implementation agencies estimate the cost of eCommerce projects? 

First of all, it’s crucial to understand how most agencies approach pricing web projects. In simple terms, the price of a given project will depend on the number and complexity of functionalities, the store’s frontend, and the technology/platform used to implement the project.

The cost of an eCommerce project varies significantly based on its complexity and scope. At the lower end, you have simple, template-based stores selling a few products locally, which are relatively inexpensive. As you move up in complexity, costs increase. A store with a large inventory (say, 10,000 products) selling internationally will be more expensive due to its scale and the additional features required for global sales. B2B eCommerce platforms often cost more than B2C stores because of their specialized features and complex pricing structures. At the top end of the price spectrum, you’ll find marketplace projects, which involve multiple sellers and various interactions, making them generally the most expensive to develop and maintain.

To simplify this matter greatly, the more complex the store, the more lines of code need to be written, or the more plugins/extensions of a given platform need to be used. To estimate “how many lines of code” need to be written to make the entire store reflect the client’s vision, the project needs to be broken down into so-called functionalities. These functionalities can relate to what we see as users (on the store’s frontend) – such as banners, photo galleries, appropriate page design, or what happens behind the scenes (on the backend) – for example, promotion logic, integration with external systems like PIM, ERP, etc.

Naturally, this is only a simplification of how this process works. Other elements to consider include, for example, technology/platform choice, the agency’s approach to pricing, the billing model with the agency, licenses, platform optimizations, chosen application architecture, and so on.

It’s worth being well aware of eCommerce project costs as this will allow us to analyze offers better and choose the appropriate technology and agency, which will significantly contribute to the success of our business.

What is functionality, and how can it be properly documented? 

Simply put, functionality is nothing more than a given eCommerce feature that performs a specific task. For better understanding, let’s take the example of our client, Mytheresa:

mytheresa shop

Breaking down a section of the home page, we can see (from right)

  • Cart functionality 
  • Wishlist (add a product to favorites)
  • Login option 
  • Changing language: Polish / English
  • Product categories 
  • A banner on the home page’s main screen leads to a particular product category.   

Now, let’s assume a research scenario in which we need an estimated price for implementing a specific eCommerce feature. Without providing a graphic mockup, the agency may interpret the requirements differently. This can lead to varying interpretations of the project scope, for example:

In one project, the wishlist may look like this:

As we can see, this example includes a standard wishlist functionality, along with the ability to sort products within the wishlist. However, in a different project, the term “wishlist” might be interpreted in a different way, for example: 

In other words, we have options here for having multiple wishlists in one eCommerce platform, the ability to export a wishlist to a CSV file, the option to change the number of products in the wishlist, and bulk actions that allow us to perform various functions as listed below:

Therefore, when defining our requirements, we should focus on describing the given functionality as precisely as possible. A good practice is to describe the functionality in enough detail that even a less experienced team member can accurately replicate what it is supposed to do. Below are a few more examples that illustrate this aspect: 

❌ My eCommerce should have the ability to securely log in and ensure that every customer can conveniently shop on their account.

✅ Ability to log into the store via Google, Apple, and Facebook accounts, with the option to complete an order at the checkout stage without the need to log in. Ability to edit personal data and marketing consents.

❌ Ability to manage products from the admin panel.

✅ The store allows adding, editing, and deleting products. It supports various product categories, taking into account multiple attributes, codes, prices, and stock levels.

❌ Support for multiple currencies and languages.

✅ The store is available in English, Polish, French, and Swedish. Currencies available in the store are PLN, EUR, and SEK. The language and localization of the store are set automatically based on the user’s browser settings.

Functionalities may also relate to more back-office elements of the eCommerce:

❌ I want not everyone on the team to have access to all information in the admin panel.

✅ Ability to assign roles and access to selected eCommerce functionalities. I would like to have the ability to assign a super administrator role and create an account for an employee where they will only have access to orders coming into the store.

While the descriptions we’ve discussed are correct, they would still leave considerable room for interpretation if handed directly to a developer for implementation. To create a truly comprehensive specification, we would need to describe each functionality in even greater detail.

This more precise description should include how the functionality should appear on the store’s front-end, how it should work, the acceptance criteria, and a detailed walkthrough of the customer’s journey through the feature. However, for the purpose of estimation, pricing, and comparing technologies, the level of description presented above may be entirely sufficient, and the role of further clarifying tasks is typically taken on during dedicated workshops. 

Vision-To-Plan 
eCommerce Workshops

Learn more

With our overview of eCommerce functionality complete, let’s discuss how to prepare the comprehensive documentation. 

What should project documentation include?

Based on hundreds of project documentation and requests for proposals we’ve worked on, below is a general structure for documentation that typically allows for an efficient and effective bidding process with the seller. Here’s an example structure:

Introduction/Client Description

In this section, it’s valuable to briefly describe who we are, what our business looks like, or how we plan for it to look. While it might seem obvious and could be considered the seller’s responsibility to research this information online or relay it to the team after a meeting, it’s important to remember that project estimation involves not just the consultant present at the meeting but a whole range of developers and staff within the company.

Often, project documentation is passed to another person for pricing. By providing a background in a prepared document, we ensure that the person pricing the project will understand the company’s background exactly as we want it presented. It’s crucial to include context relevant to the project’s implementation and the business goals we aim to achieve both in the long and short term.

It’s important to clearly define what we need from the company. For example, the term “eCommerce implementation” could encompass:

  • Preparation of store design
  • Backend technology implementation
  • Store frontend implementation
  • Store maintenance after going live
  • SEO and SEM services
  • Recruitment of developers for the specific technology after going live
  • Implementation of PIM, ERP, and other systems around eCommerce
  • Building microservices
  • and often much more …

Therefore, if we have any specific requirements for collaboration, it’s worth outlining them here. A common requirement is the project pricing model. Some companies prefer to work in a Time & Materials model, while others prefer Fixed Price.

Deadline for submitting offers and approximate project timeline

This is not a mandatory point, but by indicating to the agency our expectations regarding the deadline for receiving estimates and outlining how we plan to break down the project timeline, we significantly facilitate the work of the agency preparing the estimates, as well as potentially influencing the choice of technology. For example – if we need the complex store to launch in 2 months, we probably won’t be able to do it on Magento or Sylius; instead, we’ll be looking for simplifications and leaning towards more out-of-the-box solutions.

Functionalities requirements 

The key part of project documentation is the description of all necessary functionalities. Below, we’ve included a few questions that will initially help to prepare a list of functionalities if they are not well-defined yet. However, remember to formulate the functionalities correctly as mentioned in the previous point.

Business Model

  • What is the business model for the project? (B2B, B2C, etc.)
  • What does the store’s business model look like?
  • Will sales be conducted only in the local market or also internationally? If internationally, which markets will be targeted?
  • What are the preferences regarding payment methods in the target markets?
  • Does the project will be a standard eCommerce or a Multi-Vendor Marketplace?
If Multi-Vendor Marketplace:
  • Who will play the role of vendor?
  • How many vendors do we anticipate in total?
  • What is the settlement model between the vendor and administrator: fixed subscription or commission?
  • What functionalities should the vendor’s administrative panel include?

General questions

  • What information is required when a customer registers an account?
  • In which currencies will purchases be available?
  • In how many languages should the store be available?
  • How many sales channels will be present in the store?
  • Should the site include a search engine? If so, how should it work, and by what criteria should it suggest products?
  • How many people will have access to the administrator panel, and with what roles?
  • What static pages will be available in the store?
  • What should the site structure and menu look like?
  • Do we plan to implement promotions or loyalty programs in the store?
  • Will subscription products be available in the store?
  • Should there be an option in the administrative panel to divide users into roles with specific permissions?

Products

  • What type of products will be offered: physical or digital?
  • How are product categories planned?
  • What is the number of products and their variants?
  • Do the products require personalization? If so, what personalization options are needed?
  • Where will the products be stored, and how are they connected to the system?
  • Where will the inventory information be stored?
  • How should products be filtered (e.g., Elasticsearch)?
  • Will the store offer a wishlist?
  • Do we anticipate cross-selling or up-selling? If so, where should it appear?
  • Will product bundles be available in the store?
  • Do we want a “quick overview” of the product when hovering the cursor?

Payment Methods

  • Does the store have an agreement with any payment gateway?
  • Which payment gateways are being considered?

Logistics

  • What does the logistic process and product shipping look like in the store?
  • Are there any planned brick-and-mortar store locations?
  • What delivery options will be available (e.g., standard delivery, express, same-day)?
  • Will customers be able to track their shipments?
  • What are the delivery limits, e.g., free delivery above a certain amount?

Orders

  • What does the entire purchase process look like?
  • Do we anticipate the possibility of purchasing without logging in?
  • Should the purchase process be multi-stage or in the form of a single-page checkout?
  • Will customers be able to save their cart for later?
  • Do we plan reminders about abandoned carts?
  • Will it be possible to edit orders after they’ve been placed (e.g., changing addresses, adding/removing products)?

External integrations

  • What tools should the store integrate with (CRM, CMS, ERP, PIM, Marketing automation, etc.)?
  • What data will be exchanged as part of the integration?
  • What are the reasons for integration with particular tools? What needs should these integrations satisfy?
  • Do we plan to integrate with social platforms (e.g., logging in via Facebook or Google)?
  • Do we plan to integrate with price comparison sites (e.g., Ceneo, Google Shopping)?

Design and UI/UX

  • Who will be responsible for the store’s design?
  • Are we considering implementing headless commerce?
  • Should the store operate in a PWA (Progressive Web App) model?
  • What frontend technologies does the provider recommend?

Marketing and SEO

  • What marketing tools do we want to use (e.g., automatic reports)?
  • Should the store have extensive SEO features (e.g., automatic tag generation, SEO-friendly URLs)?
  • Do we anticipate retargeting mechanisms (e.g., ads reminding us about abandoned carts)?
  • What metrics and KPIs are crucial (e.g., conversions, abandoned carts)?
  • Do we plan functionality for automatic sales reports?

CMS (Content Management)

  • Are we planning dynamic elements on the page (e.g., rotating banners)?
  • Do we anticipate the possibility of content management by multiple users simultaneously (e.g., content in multiple languages)?

Security

  • What are the data security requirements (e.g., GDPR compliance)?
  • Do we consider mechanisms for monitoring suspicious activities (e.g., protection against bots)?

Additional features

  • Will there be pop-ups in the store?
  • Do we anticipate sending newsletters?
  • Are we planning to implement a chatbot?
  • Should the store have offline functionality (for PWA)?
  • Do we anticipate an API for external applications?
  • What are the requirements for project scalability – how many simultaneous users do we anticipate at the start and in the future?

For the purpose of this article, we have also prepared an example of eCommerce functionality documentation. This is only an example – your documentation can be less or more extensive. 

Summary

Preparing functional documentation before meeting with an implementation agency is a crucial step that brings many benefits. By properly listing the eCommerce functionalities you plan to implement, you ensure:

  • Better understanding of your needs – The process of writing down requirements helps organize thoughts and better define project goals.
  • More accurate pricing – Thanks to precisely described functionalities, agencies can more accurately estimate the time and costs of implementation.
  • Ability to compare offers and technologies – Having uniform documentation makes it easier to compare different offers and technological approaches.
  • Reduced risk of misunderstandings – Clear documentation helps avoid ambiguities between you and the agency, which accelerates the project implementation process.
  • Time savings – Documentation eliminates the need to repeatedly explain requirements to the agency and allows for faster progression to implementation.

Functional documentation is also crucial in the context of more complex projects, such as marketplaces or B2B shops, where precise descriptions of functionalities are of crucial importance. Through proper preparation and detailed description, you’re able to create a foundation that will help not only in pricing but also in the future success of your eCommerce venture.

If you are looking an eCommerce development company, check our services >>>