#          

# Project Specification

| Client | Version | Date Prepared |
| :---- | :---- | :---- |
| Europa | V1 | 27.04.2026 |

Prepared By  
Tom Jones  
Matt Ainsworth  
Ben Ost  
Lydia Thorne

# Table of Contents: {#table-of-contents:}

[**Table of Contents:	2**](#table-of-contents:)

[**Purpose of this document	5**](#purpose-of-this-document)

[**How to use this document	5**](#how-to-use-this-document)

[**Document structure	6**](#document-structure)

[**Review status / how to feed back	6**](#review-status-/-how-to-feed-back)

[**Ownership Breakdown	8**](#ownership-breakdown)

[**Sitemap	9**](#sitemap)

[**Page Requirements	10**](#page-requirements)

[Homepage	10](#homepage)

[Product Category	10](#product-category)

[Product Search Results	12](#product-search-results)

[Product Detail Page	12](#product-detail-page)

[Basket	14](#basket)

[Checkout	16](#checkout)

[Order Confirmation	18](#order-confirmation)

[Login	19](#login)

[Register	20](#register)

[Reset / Forgot Password	21](#reset-/-forgot-password)

[Email Verification	21](#email-verification)

[Account Access Pending	22](#account-access-pending)

[Account Access Unable / Rejected	22](#account-access-unable-/-rejected)

[Account Dashboard	23](#account-dashboard)

[Returns and Support messages	24](#returns-and-support-messages)

[Saved lists / favourites	25](#saved-lists-/-favourites)

[Order history / Invoices	25](#order-history-/-invoices)

[Account Users / Permissions	26](#account-users-/-permissions)

[Members dashboard	26](#members-dashboard)

[CPD Course Listing	27](#cpd-course-listing)

[CPD Course Detail	28](#cpd-course-detail)

[Certificates	28](#certificates)

[Resource Hub	29](#resource-hub)

[Article / Guide	30](#article-/-guide)

[Download Page	30](#download-page)

[Contact / Support	31](#contact-/-support)

[Page Builder Page	32](#page-builder-page)

[**Cross-site functional requirements	34**](#cross-site-functional-requirements)

[Search and filtering	34](#search-and-filtering)

[Navigation	35](#navigation)

[Forms	35](#forms)

[CMS Editing	36](#cms-editing)

[CMS	37](#cms)

[SEO	37](#seo)

[Analytics	38](#analytics)

[Accessibility	39](#accessibility)

[Responsiveness	39](#responsiveness)

[Performance	40](#performance)

[Authentication	40](#authentication)

[Role-Based Access	41](#role-based-access)

[Notifications	42](#notifications)

[Cookie Consent and Privacy	43](#cookie-consent-and-privacy)

[Live Chat and Support	43](#live-chat-and-support)

[**Supporting technical detail	45**](#supporting-technical-detail)

[Architecture Overview	45](#architecture-overview)

[CMS and Content Model	46](#cms-and-content-model)

[Page Builder	47](#page-builder)

[Product Data & EPIM	47](#product-data-&-epim)

[Product Attributes, Taxonomy & Filtering	48](#product-attributes,-taxonomy-&-filtering)

[Product Attributes	48](#product-attributes)

[Taxonomy and Categories	49](#taxonomy-and-categories)

[Filtering Strategy	49](#filtering-strategy)

[Data Handling	49](#data-handling)

[Search Behaviour	50](#search-behaviour)

[Search Scope	50](#search-scope)

[Product search behaviour	50](#product-search-behaviour)

[Synonyms and equivalent terms	50](#synonyms-and-equivalent-terms)

[Search indexing and data flow	51](#search-indexing-and-data-flow)

[Product Visibility & Restricted Products	51](#product-visibility-&-restricted-products)

[Pricing flow	52](#pricing-flow)

[Product hold statuses	52](#product-hold-statuses)

[Syspro ERP flow	53](#syspro-erp-flow)

[Syspro SQL Data Mapping (Pricing & Customer Context)	55](#syspro-sql-data-mapping-\(pricing-&-customer-context\))

[Billing	56](#billing)

[Promotions & Special Pricing	57](#promotions-&-special-pricing)

[Currency	58](#currency)

[Stock & Availability	58](#stock-&-availability)

[Basket & Ordering	58](#basket-&-ordering)

[Checkout	59](#checkout-1)

[Orders & Order Processing	59](#orders-&-order-processing)

[Payments	59](#payments)

[Account Access & Customer Permissions	60](#account-access-&-customer-permissions)

[Account Onboarding & Approval	61](#account-onboarding-&-approval)

[Account Dashboard & Self-Service	61](#account-dashboard-&-self-service)

[Members Area & CPD	63](#members-area-&-cpd)

[Documents, Downloads & Resources	63](#documents,-downloads-&-resources)

[Forms, Enquiries & Support	64](#forms,-enquiries-&-support)

[Live Chat / Support Integration	64](#live-chat-/-support-integration)

[Data Switch & Integration Flows	65](#data-switch-&-integration-flows)

[Cached Data Layer	65](#cached-data-layer)

[Synchronisation Strategy	65](#synchronisation-strategy)

[Data Quality & Validation	66](#data-quality-&-validation)

[Security & Access Control	67](#security-&-access-control)

[Admin Access & Permissions	68](#admin-access-&-permissions)

[Analytics & Tracking	69](#analytics-&-tracking)

[SEO	69](#seo-1)

[Accessibility	70](#accessibility-1)

[Performance	70](#performance-1)

[Environments, Testing & Deployment	71](#environments,-testing-&-deployment)

[Environments	71](#environments)

[Testing approach	72](#testing-approach)

[User acceptance testing	73](#user-acceptance-testing)

[Deployment approach	74](#deployment-approach)

[Appendix: Project Terminology	76](#appendix:-project-terminology)

# 

# Purpose of this document {#purpose-of-this-document}

This document defines the agreed project specification for the Europa website.

It is intended to give Europa stakeholders and the Platform team a shared reference point for the website scope, page requirements, cross-site functionality, system integrations and supporting technical detail.

The document is structured so that stakeholders can first review the areas most relevant to them, before following links into deeper functional or technical sections where more detail is required.

This specification should be used to:

* Confirm the agreed website pages, templates and functional areas.  
* Give each Europa lead a clear route to the pages and requirements relevant to their area.  
* Link page-level requirements to the wider technical and integration detail.  
* Support design, development, testing, validation and sign-off.  
* Highlight assumptions, dependencies and areas requiring further confirmation.

# How to use this document {#how-to-use-this-document}

This document is designed to be read in layers.

Stakeholders do not need to read every technical section in full. The recommended approach is:

1. Use the [Ownership Breakdown](#ownership-breakdown) to identify the project area and relevant page templates.  
2. Review the relevant page breakdowns in the Page Requirements section.  
3. Follow the links from each page breakdown into the related cross-site or technical sections where more detail is needed.  
4. Review any assumptions, dependencies or confirmation points linked to that area.  
5. Provide feedback against the relevant section, page or requirement ID.

The Page Requirements section is intended to be the main entry point for most Europa stakeholders. Each page includes a short description, key requirements and links to deeper detail covering systems, data, integrations, permissions, pricing, CMS behaviour and non-functional requirements.

The Supporting Technical Detail section is intended for stakeholders who need to validate system behaviour, integrations, data ownership, architecture, security, performance or backend logic.

# Document structure {#document-structure}

The specification is organised into the following sections:

| Section | Purpose |
| :---- | :---- |
| Ownership Breakdown | Helps stakeholders quickly find the pages and requirements relevant to their project area. |
| Sitemap | Provides a draft top-level view of the proposed website structure and navigation. |
| Page Requirements | Breaks the website down page-by-page or template-by-template, with key requirements and links to deeper detail. |
| Cross-site functional requirements | Covers functionality that applies across multiple pages, such as navigation, search, forms, CMS editing, accessibility, performance and authentication. |
| Supporting technical detail | Provides deeper detail on architecture, CMS, EPIM, Syspro, pricing, stock, checkout, account permissions, integrations, security and deployment. |

# Review status / how to feed back {#review-status-/-how-to-feed-back}

This document is a working project specification and should be reviewed by the relevant Europa leads before final approval.

Feedback should be provided against the relevant section, page template or requirement ID wherever possible.

Where feedback affects data ownership, pricing, product visibility, account permissions, checkout, order processing or integrations, it should be reviewed with the relevant Europa lead and Platform technical owner before being accepted into scope.

Any new requirements, changes to agreed functionality or areas requiring further discovery should be logged as either:

| Status | Meaning |
| :---- | :---- |
| Confirmed | Agreed and ready to proceed into design/development planning. |
| Needs validation | Directionally agreed, but requires confirmation from the relevant Europa stakeholder or sample data. |
| Out of current scope | Not included in the current phase unless separately agreed. |
| Future consideration | Useful or desirable, but not required for phase one. |

# Ownership Breakdown {#ownership-breakdown}

| Project Area | Europa Lead | Relevant Pages |
| :---- | :---- | :---- |
| Creative, user experience, and user interfaces | Jo | [Homepage](#homepage) [Product Category](#product-category) [Product Search Results](#product-search-results) [Product Detail Page](#product-detail-page) [Resource Hub](#resource-hub) [Article / Guide](#article-/-guide) [Download Page](#download-page) [Contact / Support](#contact-/-support) [Page Builder Page](#page-builder-page) |
| Content, structure, and CMS | Jo | [Homepage](#homepage) [Resource Hub](#resource-hub) [Article / Guide](#article-/-guide) [Download Page](#download-page) [Contact / Support](#contact-/-support) [Page Builder Page](#page-builder-page) |
| Product data, structure, and EPIM | Steve | [Product Category](#product-category) [Product Search Results](#product-search-results) [Product Detail Page](#product-detail-page) [Saved Lists / Favourites](#saved-lists-/-favourites) [Order History / Invoices](#order-history-/-invoices) [Resource Hub](#resource-hub) [Download Page](#download-page) |
| Pricing, commercial rules, and visibility | Steve | [Product Category](#product-category) [Product Search Results](#product-search-results) [Product Detail Page](#product-detail-page) [Basket](#basket) [Checkout](#checkout) [Order Confirmation](#order-confirmation) [Saved Lists / Favourites](#saved-lists-/-favourites) [Order History / Invoices](#order-history-/-invoices) |
| Account management and customer experience | Chloe | [Basket](#basket) [Checkout](#checkout) [Order Confirmation](#order-confirmation) [Login](#login) [Register](#register) [Reset / Forgot Password](#reset-/-forgot-password) [Email Verification](#email-verification) [Account Access Pending](#account-access-pending) [Account Access Unable / Rejected](#account-access-unable-/-rejected) [Account Dashboard](#account-dashboard) [Returns and Support Messages](#returns-and-support-messages) [Saved Lists / Favourites](#saved-lists-/-favourites) [Order History / Invoices](#order-history-/-invoices) [Account Users / Permissions](#account-users-/-permissions) [Members Dashboard](#members-dashboard) [CPD Course Listing](#cpd-course-listing) [CPD Course Detail](#cpd-course-detail) [Certificates](#certificates) [Contact / Support](#contact-/-support) |

# Sitemap {#sitemap}

The following sitemap provides a draft, top-level view of the proposed website structure for this project. It is intended to illustrate the primary navigation, key content areas, and overall information architecture at a high level, forming the foundation for a fully developed sitemap.

This will act as a requirements checklist for all page template structure recommendations and designs, ensuring consistency across the site and alignment with both user needs and project objectives. At this stage, the sitemap is presented for review and discussion, and we welcome feedback to help refine the structure, identify any omissions, and confirm the proposed approach before progressing further.

[You can access the draft sitemap here](https://www.figma.com/board/65bETv0xvzfuXrR4buWI1R/Site-Map---User-Journeys?node-id=0-1&p=f&t=d7dUUD71NraaVUSF-0)

# Page Requirements {#page-requirements}

This section outlines the key page templates and functional areas expected within the website.

Each page includes a short description, its core requirements, and links to the wider functional or technical sections where more detail is provided. This allows stakeholders to review the website page-by-page first, before moving into the deeper detail around systems, data, integrations, permissions, pricing and CMS behaviour.

Pages should be read as templates or functional areas rather than fixed static pages. CMS-managed content pages can be created using the page builder where they do not require unique product, account, pricing or transactional logic.

### Homepage {#homepage}

The homepage will introduce Europa, help users understand what the business does, and direct users quickly into key journeys such as products, account access, resources, services and support. This template will be constructed using the page builder.

| ID | Key Requirement | Priority |
| :---- | :---- | :---- |
| REQ-CMS-001 | The CMS shall allow approved users to create, edit and publish CMS-managed content. | Must |
| REQ-CMS-002 | The CMS shall support structured content types for pages, articles, resources, downloads, landing pages and navigation. | Must |
| REQ-PB-001 | The page builder shall allow approved users to create flexible content-led pages using predefined components. | Must |
| REQ-PB-002 | The page builder shall provide reusable components such as hero, text, media, CTAs, grids, banners, embeds and forms. | Must |
| REQ-ANL-006 | CTA interactions shall be tracked where required. | Should |

Further detail is covered in the sections on [Navigation](#navigation), [CMS and Content Model](#cms-and-content-model), [Page Builder](#page-builder), and [Analytics & Tracking](#analytics-&-tracking).

### Product Category  {#product-category}

Allows users to browse products within a defined product category, using structured filters and category-level content to support discovery and SEO. 

| ID | Key Requirements | Priority |
| :---- | :---- | :---- |
| REQ-ARCH-005 | A cached data layer shall be used where appropriate to support performance, search, product listing and pricing-support data. | Must |
| REQ-PROD-001 | Product data displayed on the website shall originate from EPIM. | Must |
| REQ-PROD-002 | Product category pages shall display products belonging to the relevant EPIM category. | Must |
| REQ-PROD-005 | Product data shall not be manually recreated or maintained in the CMS unless explicitly identified as CMS-owned content. | Must |
| REQ-PROD-006 | Product attributes shall use structured EPIM data, including ETIM / EDATA where available. | Must |
| REQ-PROD-007 | Product filtering shall be driven by structured attributes rather than free-text parsing or manually configured filters. | Must |
| REQ-PROD-008 | Category-specific filter sets shall be supported. | Must |
| REQ-PROD-009 | Product listing and search pages shall allow sorting and refinement. | Must |
| REQ-PROD-010 | Restricted or customer-specific products shall not be exposed to unauthorised users. | Must |
| REQ-PROD-011 | Product visibility rules shall apply to listings, search, PDPs, saved lists, basket and checkout. | Must |
| REQ-PROD-014 | Product publication, inactive, discontinued, partial-hold, full-hold and restricted states shall be respected by the website. | Must |
| REQ-PROD-015 | Products shall not be exposed for sale where upstream status rules indicate they should not be purchasable. | Must |
| REQ-PROD-016 | Partial-hold and full-hold product statuses shall be displayed to customers using agreed availability and discontinued-product messaging. | Must |
| REQ-SEARCH-002 | Product search shall support SKU, product name, description, category and brand where data allows. | Must |
| REQ-SEARCH-007 | Search results shall respect account permissions, buying access and product visibility rules. | Must |
| REQ-SEARCH-008 | Search indexing shall account for product publication status, CMS updates and removed/unpublished content. | Must |
| REQ-SEO-001 | CMS users shall be able to manage page titles and meta descriptions. | Must |
| REQ-SEO-007 | SEO-friendly category and landing page content shall be supported. | Must |
| REQ-RESP-002 | Product browsing, filters, basket and checkout shall be mobile-friendly. | Must |
| REQ-PERF-005 | Product lists and filtered results shall remain performant at scale. | Must |
| REQ-ERR-005 | Removed, unpublished or restricted products shall be handled gracefully without exposing restricted information. | Must |

Further detail is covered in the sections on [Search and Filtering](#search-and-filtering), [Product Data & EPIM](#product-data-&-epim), [Product Attributes](#product-attributes,-taxonomy-&-filtering), [Taxonomy & Filtering](#product-attributes,-taxonomy-&-filtering), and [Product Visibility & Restricted Products](#product-visibility-&-restricted-products).

### Product Search Results {#product-search-results}

The results shown from a product search will display products based on a user’s search query, allowing users to refine, sort and navigate to relevant product detail pages.

| ID | Key Requirement | Priority |
| :---- | :---- | :---- |
| REQ-PROD-001 | Product data displayed on the website shall originate from EPIM. | Must |
| REQ-PROD-006 | Product attributes shall use structured EPIM data, including ETIM / EDATA where available. | Must |
| REQ-PROD-007 | Product filtering shall be driven by structured attributes rather than free-text parsing or manually configured filters. | Must |
| REQ-PROD-008 | Category-specific filter sets shall be supported. | Must |
| REQ-PROD-009 | Product listing and search pages shall allow sorting and refinement. | Must |
| REQ-PROD-010 | Restricted or customer-specific products shall not be exposed to unauthorised users. | Must |
| REQ-PROD-011 | Product visibility rules shall apply to listings, search, PDPs, saved lists, basket and checkout. | Must |
| REQ-PROD-014 | Product publication, inactive, discontinued, partial-hold, full-hold and restricted states shall be respected by the website. | Must |
| REQ-SEARCH-003 | Product search results shall default to relevance-based sorting. | Must |
| REQ-SEARCH-004 | Search result pages shall provide relevant filters. | Must |
| REQ-SEARCH-007 | Search results shall respect account permissions, buying access and product visibility rules. | Must |
| REQ-SEARCH-008 | Search indexing shall account for product publication status, CMS updates and removed/unpublished content. | Must |
| REQ-SEARCH-006 | Search shall support synonyms or equivalent terms where required. | Should |

Further detail is covered in the sections on [Search and Filtering](#search-and-filtering), [Search Behaviour,](#search-behaviour) [Product Attributes](#product-attributes,-taxonomy-&-filtering), [Taxonomy & Filtering](#product-attributes,-taxonomy-&-filtering), and [Product Visibility & Restricted Products](#product-visibility-&-restricted-products).

### Product Detail Page {#product-detail-page}

The product detail page allows users to view product information, pricing, stock/availability and purchasing options.

| ID | Key Requirement | Priority |
| :---- | ----- | :---- |
| REQ-PROD-003 | Product detail pages shall display EPIM product descriptions, attributes, images and downloads. | Must |
| REQ-PROD-004 | Product assets such as images and datasheets shall come from EPIM where EPIM owns them. | Must |
| REQ-PROD-005 | Product data shall not be manually recreated or maintained in the CMS unless explicitly identified as CMS-owned content. | Must |
| REQ-PROD-010 | Restricted or customer-specific products shall not be exposed to unauthorised users. | Must |
| REQ-PROD-011 | Product visibility rules shall apply to listings, search, PDPs, saved lists, basket and checkout. | Must |
| REQ-PROD-013 | Eligible users shall be able to save or favourite products where account functionality allows. | Should |
| REQ-PROD-014 | Product publication, inactive, discontinued, partial-hold, full-hold and restricted states shall be respected by the website. | Must |
| REQ-PROD-015 | Products shall not be exposed for sale where upstream status rules indicate they should not be purchasable. | Must |
| REQ-PROD-016 | Partial-hold and full-hold product statuses shall be displayed to customers using agreed availability and discontinued-product messaging. | Must |
| REQ-TAX-001 | Pricing and checkout totals shall display tax/VAT treatment according to the agreed business rules. | Must |
| REQ-PRICE-001 | Pricing shall be resolved by the backend and shall not be calculated in the frontend. | Must |
| REQ-PRICE-002 | Customer-specific pricing shall be displayed where the user is logged in and eligible. | Must |
| REQ-STOCK-001 | Stock and availability data shall originate from Syspro or the agreed Syspro-derived data source. | Must |
| REQ-STOCK-002 | Product pages shall display stock or availability messaging where data is available. | Must |
| REQ-STOCK-004 | Availability / Deliverability messaging shall not imply real-time certainty; copy needed | Must |
| REQ-STOCK-005 | Backorder behaviour shall be supported where required by business process. | Should |
| REQ-BASKET-001 | Eligible users shall be able to add permitted products to basket. | Must |
| REQ-ACC-002 | Purchasing access shall be restricted until approval/permissions allow. | Must |
| REQ-DOC-004 | Product assets and datasheets shall be distinguished from CMS-managed downloads. | Must |
| REQ-SUPPORT-006 | Live chat and support contact options where agreed. | Should |
| REQ-PROD-012 | Related or alternative products shall be shown where data is available. | Should |

Further detail is covered in the sections on [Product Data & EPIM](#product-data-&-epim), [Syspro Pricing & Billing](#pricing-flow), [Stock & Availability](#stock-&-availability), and [Product Visibility & Restricted Products](#product-visibility-&-restricted-products).

### Basket {#basket}

The basket allows users to review selected products before checkout, update quantities, view pricing summaries and proceed to purchase.

| ID | Key Requirement | Priority |
| :---- | :---- | :---- |
| REQ-ARCH-005 | A cached data layer shall be used where appropriate to support performance, search, product listing and pricing-support data. | Must |
| REQ-PROD-010 | Restricted or customer-specific products shall not be exposed to unauthorised users. | Must |
| REQ-PROD-011 | Product visibility rules shall apply to listings, search, PDPs, saved lists, basket and checkout. | Must |
| REQ-PROD-014 | Product publication, inactive, discontinued, partial-hold, full-hold and restricted states shall be respected by the website. | Must |
| REQ-PROD-015 | Products shall not be exposed for sale where upstream status rules indicate they should not be purchasable. | Must |
| REQ-PROD-016 | Partial-hold and full-hold product statuses shall be displayed to customers using agreed availability and discontinued-product messaging. | Must |
| REQ-TAX-001 | Pricing and checkout totals shall display tax/VAT treatment according to the agreed business rules. | Must |
| REQ-PRICE-001 | Pricing shall be resolved by the backend and shall not be calculated in the frontend. | Must |
| REQ-PRICE-002 | Customer-specific pricing shall be displayed where the user is logged in and eligible. | Must |
| REQ-PRICE-003 | Pricing shall use Syspro-derived pricing data and agreed backend pricing logic. | Must |
| REQ-PRICE-004 | Pricing shall account for contract pricing, standard pricing, discounts, quantity breaks, promotions and currency where applicable. | Must |
| REQ-PRICE-005 | Pricing resolution shall consider price priority, effective dates, customer context and product context. | Must |
| REQ-PRICE-006 | Basket totals shall be recalculated when quantities or basket contents change. | Must |
| REQ-PRICE-007 | Promotional pricing shall be resolved through backend pricing logic, not hard-coded in the CMS or frontend. | Must |
| REQ-PRICE-008 | Currency handling shall be driven by account/customer context and backend pricing logic. | Must |
| REQ-STOCK-001 | Stock and availability data shall originate from Syspro or the agreed Syspro-derived data source. | Must |
| REQ-STOCK-003 | Basket and checkout shall surface relevant stock or availability messaging. | Must |
| REQ-STOCK-004 | Availability / Deliverability messaging shall not imply real-time certainty; copy needed | Must |
| REQ-STOCK-005 | Backorder behaviour shall be supported where required by business process. | Should |
| REQ-BASKET-001 | Eligible users shall be able to add permitted products to basket. | Must |
| REQ-BASKET-002 | Basket shall display selected products, quantities and customer-specific pricing summary. | Must |
| REQ-BASKET-003 | Users shall be able to update quantities and remove items. | Must |
| REQ-BASKET-004 | Basket contents shall be revalidated against pricing, stock, visibility and account permissions before checkout. | Must |
| REQ-BASKET-005 | Basket persistence across sessions/devices shall be supported where agreed. | Should |
| REQ-BASKET-006 | Saved products/lists shall be revalidated when reused. | Must |
| REQ-ORDER-008 | Reorder functionality shall be supported where appropriate. | Should |
| REQ-ACC-002 | Purchasing access shall be restricted until approval/permissions allow. | Must |
| REQ-ANL-002 | Search, product views, basket and checkout journeys shall be tracked. | Must |
| REQ-RESP-002 | Product browsing, filters, basket and checkout shall be mobile-friendly. | Must |
| REQ-PERF-004 | Content and API caching strategies shall be implemented where appropriate. | Must |
| REQ-PERF-006 | Login, basket and checkout shall remain reliable under normal traffic loads. | Must |
| REQ-DATA-003 | Pricing-support data shall be validated before use by backend pricing logic. | Must |
| REQ-TEST-003 | Pricing validation shall cover customer pricing, contract pricing, QDB, promotions and fallback scenarios. | Must |

Further detail is covered in the sections on [Basket & Ordering](#basket-&-ordering), [Syspro Pricing & Billing](#pricing-flow), [Stock & Availability](#stock-&-availability), [Product Visibility & Restricted Products](#product-visibility-&-restricted-products) and [Account Access & Customer Permissions](#account-access-&-customer-permissions).

### Checkout {#checkout}

The checkout allows eligible users to complete an order by confirming delivery, billing, payment via account and order details.

| ID | Key Requirement | Priority |
| :---- | :---- | :---- |
| REQ-ARCH-005 | A cached data layer shall be used where appropriate to support performance, search, product listing and pricing-support data. | Must |
| REQ-PROD-010 | Restricted or customer-specific products shall not be exposed to unauthorised users. | Must |
| REQ-PROD-011 | Product visibility rules shall apply to listings, search, PDPs, saved lists, basket and checkout. | Must |
| REQ-ERR-003 | The system shall define fallback behaviour where upstream data feeds are unavailable, delayed or stale. | Must |
| REQ-PROD-014 | Product publication, inactive, discontinued, partial-hold, full-hold and restricted states shall be respected by the website. | Must |
| REQ-PROD-015 | Products shall not be exposed for sale where upstream status rules indicate they should not be purchasable. | Must |
| REQ-PROD-016 | Partial-hold and full-hold product statuses shall be displayed to customers using agreed availability and discontinued-product messaging. | Must |
| REQ-TAX-001 | Pricing and checkout totals shall display tax/VAT treatment according to the agreed business rules. | Must |
| REQ-TAX-002 | Order submission shall include required tax/VAT values or flags for downstream processing. | Must |
| REQ-PRICE-001 | Pricing shall be resolved by the backend and shall not be calculated in the frontend. | Must |
| REQ-PRICE-002 | Customer-specific pricing shall be displayed where the user is logged in and eligible. | Must |
| REQ-PRICE-003 | Pricing shall use Syspro-derived pricing data and agreed backend pricing logic. | Must |
| REQ-PRICE-004 | Pricing shall account for contract pricing, standard pricing, discounts, quantity breaks, promotions and currency where applicable. | Must |
| REQ-PRICE-005 | Pricing resolution shall consider price priority, effective dates, customer context and product context. | Must |
| REQ-PRICE-006 | Basket totals shall be recalculated when quantities or basket contents change. | Must |
| REQ-PRICE-007 | Promotional pricing shall be resolved through backend pricing logic, not hard-coded in the CMS or frontend. | Must |
| REQ-PRICE-008 | Currency handling shall be driven by account/customer context and backend pricing logic. | Must |
| REQ-STOCK-001 | Stock and availability data shall originate from Syspro or the agreed Syspro-derived data source. | Must |
| REQ-STOCK-003 | Basket and checkout shall surface relevant stock or availability messaging. | Must |
| REQ-STOCK-004 | Availability / Deliverability messaging shall not imply real-time certainty; copy needed | Must |
| REQ-STOCK-005 | Backorder behaviour shall be supported where required by business process. | Should |
| REQ-BASKET-004 | Basket contents shall be revalidated against pricing, stock, visibility and account permissions before checkout. | Must |
| REQ-CHECKOUT-001 | Checkout shall be restricted to authorised users with approved purchasing access. | Must |
| REQ-CHECKOUT-002 | Checkout shall capture or confirm delivery and billing information. | Must |
| REQ-CHECKOUT-003 | Checkout shall display a final order summary before submission. | Must |
| REQ-CHECKOUT-004 | Checkout shall validate basket contents, account permissions, pricing and availability before order submission. | Must |
| REQ-CHECKOUT-005 | Checkout shall support the agreed payment method requirements. (existing credit account flow, no card processing) | Must |
| REQ-CHECKOUT-006 | Checkout shall provide clear error handling if validation, payment or order submission fails. | Must |
| REQ-ORDER-001 | Orders shall be submitted into the agreed backend/Syspro/Data Switch order flow. | Must |
| REQ-ACC-001 | Account access and customer permissions shall be enforced by the backend. | Must |
| REQ-ACC-002 | Purchasing access shall be restricted until approval/permissions allow. | Must |
| REQ-SUPPORT-006 | Live chat and support contact options where agreed. | Should |
| REQ-ANL-002 | Search, product views, basket and checkout journeys shall be tracked. | Must |
| REQ-A11Y-007 | Interactive components shall be usable with assistive technology. | Must |
| REQ-RESP-002 | Product browsing, filters, basket and checkout shall be mobile-friendly. | Must |
| REQ-PERF-006 | Login, basket and checkout shall remain reliable under normal traffic loads. | Must |
| REQ-SEC-001 | Authentication, account areas, members areas, checkout, forms and integrations shall be secured. | Must |
| REQ-SEC-002 | The backend shall enforce permissions before returning protected data or allowing protected actions. | Must |
| REQ-SEC-003 | Error messages shall not expose sensitive data, system details or approval logic. | Must |
| REQ-SEC-004 | Personal and account-related data shall be handled securely. | Must |
| REQ-DATA-003 | Pricing-support data shall be validated before use by backend pricing logic. | Must |
| REQ-DATA-005 | Known anomalies and edge cases shall be tested using supplied sample data. | Must |
| REQ-INT-003 | Orders shall be submitted from the website/Laravel backend into the agreed Syspro order flow. | Must |
| REQ-TEST-002 | Integration testing shall cover EPIM, Syspro, Data Switch, payment, analytics and support integrations where in scope. | Must |
| REQ-TEST-003 | Pricing validation shall cover customer pricing, contract pricing, QDB, promotions and fallback scenarios. | Must |
| REQ-ERR-001 | The website shall provide clear user-facing error states for failed API requests, unavailable data, failed form submissions and failed order actions. | Must |
| REQ-ADDR-001 | Checkout shall support delivery and billing address handling based on the agreed customer/account data source. | Must |
| REQ-ADDR-002 | The system shall support users to select, add or edit delivery addresses online. | Must |
| REQ-DEL-001 | Checkout shall support agreed delivery options, delivery messaging and any required delivery charges or rules. | Must |
| REQ-DEL-003 | Delivery method, cut-off and fulfilment messaging shall be confirmed before implementation. | Must |

Further detail is covered in the sections on [Checkout](#checkout-1), [Payments](#payments), [Orders & Order Processing](#orders-&-order-processing), and [Account Access & Customer Permissions](#account-access-&-customer-permissions).

### Order Confirmation {#order-confirmation}

This screen will confirm that an order has been placed successfully and provides the user with a clear next step.

| ID | Key Requirement | Priority |
| :---- | :---- | :---- |
| REQ-TAX-002 | Order submission shall include required tax/VAT values or flags for downstream processing. | Must |
| REQ-ORDER-001 | Orders shall be submitted into the agreed backend/Syspro/Data Switch order flow. | Must |
| REQ-ORDER-002 | Order confirmation shall display submission confirmation, order reference and summary. | Must |
| REQ-ORDER-004 | Order confirmation shall clearly communicate if further backend processing is required. | Should |
| REQ-ORDER-008 | Reorder functionality shall be supported where appropriate. | Should |
| REQ-ORDER-009 | Delivery tracking shall be linked where available. | Should |
| REQ-INT-003 | Orders shall be submitted from the website/Laravel backend into the agreed Syspro order flow. | Must |
| REQ-DEL-002 | Delivery tracking shall be displayed where tracking data is available. | Should |
| REQ-DEL-003 | Delivery method, cut-off and fulfilment messaging shall be confirmed before implementation. | Must |

Further detail is covered in the sections on [Orders & Order Processing](#orders-&-order-processing), [Notifications](#notifications), and [Account Dashboard & Self-Service](#account-dashboard-&-self-service).

### Login {#login}

The login screen allows existing users to securely access their account, member area or other protected website areas.

| ID | Key Requirement | Priority |
| :---- | :---- | :---- |
| REQ-AUTH-001 | Users shall be able to log in and log out securely. | Must |
| REQ-AUTH-006 | Password reset shall avoid exposing whether an account exists. | Must |
| REQ-AUTH-009 | Secure session handling shall be supported. | Must |
| REQ-ANL-005 | Account registration and login journey performance shall be tracked where required. | Should |
| REQ-PERF-006 | Login, basket and checkout shall remain reliable under normal traffic loads. | Must |
| REQ-SEC-001 | Authentication, account areas, members areas, checkout, forms and integrations shall be secured. | Must |
| REQ-SEC-003 | Error messages shall not expose sensitive data, system details or approval logic. | Must |
| REQ-TEST-004 | Account/access testing shall cover login, registration, approval states, roles and document permissions. | Must |

Further detail is covered in the sections on [Authentication](#authentication), [Account Access & Customer Permissions](#account-access-&-customer-permissions), and [Security & Access Control](#security-&-access-control).

### Register {#register}

Allows users to start the account creation process using an existing Europa customer code and request access to relevant website areas. Email/domain validation shall be used to mitigate risk.

| ID | Key Requirement | Priority |
| :---- | :---- | :---- |
| REQ-AUTH-002 | Registration shall be supported as per the current flow. | Must |
| REQ-AUTH-007 | Email verification shall be supported where required. | Should |
| REQ-ACC-002 | Purchasing access shall be restricted until approval/permissions allow. | Must |
| REQ-ACC-003 | Registration shall capture the details needed for account verification and approval. | Must |
| REQ-ACC-004 | Registration shall validate required fields before submission. | Must |
| REQ-ACC-005 | The registration flow shall explain the approval or verification process clearly. | Must |
| REQ-ACC-006 | Registrations shall route into the agreed internal approval process where required. | Must |
| REQ-FORM-001 | Reusable form components shall be provided. | Must |
| REQ-FORM-002 | Contact, support, registration, returns, newsletter and download/lead capture forms shall be supported where required, acting as a proxy to exising europa mail flows | Must |
| REQ-FORM-004 | Forms shall provide clear validation, success and failure states. | Must |
| REQ-FORM-005 | Forms shall include spam/bot protection. | Must |
| REQ-FORM-006 | Forms shall comply with data protection and consent requirements. | Must |
| REQ-ANL-003 | Form submissions and lead capture interactions shall be tracked. | Must |
| REQ-ANL-005 | Account registration and login journey performance shall be tracked where required. | Should |
| REQ-SEC-003 | Error messages shall not expose sensitive data, system details or approval logic. | Must |
| REQ-SEC-004 | Personal and account-related data shall be handled securely. | Must |
| REQ-TEST-004 | Account/access testing shall cover login, registration, approval states, roles and document permissions. | Must |

Further detail is covered in the sections on [Authentication](#authentication), [Account Onboarding & Approval](#account-onboarding-&-approval), [Forms, Enquiries & Support](#forms,-enquiries-&-support), and [Data Quality & Validation](#data-quality-&-validation).

### Reset / Forgot Password {#reset-/-forgot-password}

Allows users to request a password reset if they cannot access their account and securely set a new password after requesting a reset.

| ID | Key Requirement | Priority |
| :---- | :---- | :---- |
| REQ-AUTH-003 | Forgotten password and reset password journeys shall be supported. | Must |
| REQ-AUTH-004 | Password reset shall use secure reset instructions and valid reset links. | Must |
| REQ-AUTH-005 | Password policy requirements shall be enforced. | Must |
| REQ-AUTH-006 | Password reset shall avoid exposing whether an account exists. | Must |
| REQ-AUTH-008 | Expired or invalid reset/verification links shall be handled clearly. | Must |
| REQ-SEC-003 | Error messages shall not expose sensitive data, system details or approval logic. | Must |

Further detail is covered in the sections on [Authentication](#authentication), [Notifications](#notifications), and [Security & Access Control](#security-&-access-control).

### Email Verification {#email-verification}

Allows users to verify ownership of their email address or domain as part of registration.

| ID | Key Requirement | Priority |
| :---- | :---- | :---- |
| REQ-AUTH-006 | Password reset shall avoid exposing whether an account exists. | Must |
| REQ-AUTH-007 | Email verification shall be supported where required. | Should |
| REQ-AUTH-008 | Expired or invalid reset/verification links shall be handled clearly. | Must |
| REQ-ERR-001 | The website shall provide clear user-facing error states for failed API requests, unavailable data, failed form submissions and failed order actions. | Must |

Further detail is covered in the sections on [Authentication](#authentication), [Notifications](#notifications), and [Account Onboarding & Approval](#account-onboarding-&-approval).

### Account Access Pending {#account-access-pending}

Informs users that their account request has been received but is awaiting approval or verification.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-ACC-005 | The registration flow shall explain the approval or verification process clearly. | Must |
| REQ-ACC-006 | Registrations shall route into the agreed internal approval process where required. | Must |
| REQ-ACC-007 | Pending users shall be shown clear account status messaging. | Must |
| REQ-ANL-005 | Account registration and login journey performance shall be tracked where required. | Should |
| REQ-ERR-001 | The website shall provide clear user-facing error states for failed API requests, unavailable data, failed form submissions and failed order actions. | Must |

Further detail is covered in the sections on [Account Onboarding & Approval](#account-onboarding-&-approval), [Account Access & Customer Permissions](#account-access-&-customer-permissions), and [Forms, Enquiries & Support](#forms,-enquiries-&-support).

### Account Access Unable / Rejected {#account-access-unable-/-rejected}

Informs users that account access cannot be granted or that their details could not be verified.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-ACC-008 | Rejected/unverified users shall be given clear messaging and a support route. | Must |
| REQ-ACC-009 | Account approval, rejection and unable-to-verify messages shall provide clear next steps without exposing internal approval criteria. | Must |
| REQ-SEC-003 | Error messages shall not expose sensitive data, system details or approval logic. | Must |
| REQ-ERR-001 | The website shall provide clear user-facing error states for failed API requests, unavailable data, failed form submissions and failed order actions. | Must |

Further detail is covered in the sections on [Account Onboarding & Approval](#account-onboarding-&-approval), [Account Access & Customer Permissions](#account-access-&-customer-permissions), and [Security & Access Control](#security-&-access-control).

### Account Dashboard {#account-dashboard}

Provides logged-in users with a central overview of their account status, recent activity, active customer-specific promotions, Custom Solutions CTA, recent orders, invoices, saved lists, returns and editable account/user details.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-NAV-006 | Secondary navigation shall be supported where required, including account and footer navigation. | Must |
| REQ-ORDER-005 | Account users shall be able to view order history where data is available. | Must |
| REQ-ORDER-008 | Reorder functionality shall be supported where appropriate. | Should |
| REQ-ORDER-009 | Delivery tracking shall be linked where available. | Should |
| REQ-AUTH-001 | Users shall be able to log in and log out securely. | Must |
| REQ-ACC-001 | Account access and customer permissions shall be enforced by the backend. | Must |
| REQ-ACC-010 | Multiple users linked to one customer account shall be supported. | Must |
| REQ-DASH-001 | Approved users shall have access to an account dashboard. | Must |
| REQ-DASH-002 | Dashboard shall link to orders, invoices, saved lists, returns and support. | Must |
| REQ-DASH-003 | Dashboard shall display relevant account status, notifications or messages where available. | Should |
| REQ-DASH-004 | Dashboard shall respect user role, customer account and permission rules. | Must |
| REQ-DASH-005 | Account users shall only see account data they are permitted to access. (all parent Europa Customer Code details) | Must |
| REQ-DOC-001 | Users shall be able to access invoices and related documents where permitted. | Must |
| REQ-SUPPORT-001 | Users shall be able to raise support enquiries from relevant areas of the site, proxied to existing Europa mail flows | Must |
| REQ-RESP-003 | Account and members areas shall be usable on mobile devices. | Must |
| REQ-SEC-004 | Personal and account-related data shall be handled securely. | Must |
| REQ-ADDR-001 | Checkout shall support delivery and billing address handling based on the agreed customer/account data source. | Must |
| REQ-ADDR-002 | The system shall support users to select, add or edit delivery addresses online. | Must |
| REQ-PROFILE-001 | Users shall be able to view their account/profile details where permitted. | Must |
| REQ-PROFILE-002 | Users shall be able to update permitted personal details and preferences where agreed. | Should |
| REQ-PROFILE-003 | Sensitive account changes shall be protected by validation and/or approval rules. | Must |

Further detail is covered in the sections on [Account Dashboard & Self-Service](#account-dashboard-&-self-service), [Account Access & Customer Permissions](#account-access-&-customer-permissions), and Role-Based Access.

### Returns and Support messages {#returns-and-support-messages}

Allows users to request support, raise returns-related enquiries and view messages linked to their account or orders.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-SUPPORT-001 | Users shall be able to raise support enquiries from relevant areas of the site, proxied to existing Europa mail flows | Must |
| REQ-SUPPORT-002 | Users shall be able to submit return-related requests via ui, triggering returns email to Europa | Should |
| REQ-SUPPORT-003 | Support or return requests shall link to relevant orders where possible. | Should |
| REQ-SUPPORT-004 | Support messages and return information shall be restricted to authorised users. | Must |
| REQ-SUPPORT-005 | Support enquiries shall route to the correct internal support process. | Must |
| REQ-FORM-001 | Reusable form components shall be provided. | Must |
| REQ-FORM-002 | Contact, support, registration, returns, newsletter and download/lead capture forms shall be supported where required, acting as a proxy to exising europa mail flows | Must |
| REQ-FORM-004 | Forms shall provide clear validation, success and failure states. | Must |
| REQ-FORM-005 | Forms shall include spam/bot protection. | Must |
| REQ-FORM-008 | Conditional fields and dynamic form behaviour shall be supported where required. | Should |
| REQ-INT-004 | live chat integration shall be implemented. Support requests should hit existing Europa support mail flows, via ui form proxy. | Should |
| REQ-ERR-001 | The website shall provide clear user-facing error states for failed API requests, unavailable data, failed form submissions and failed order actions. | Must |

Further detail is covered in the sections on [Forms, Enquiries & Support](#forms,-enquiries-&-support), [Live Chat / Support Integration](#live-chat-/-support-integration), and [Account Dashboard & Self-Service](#account-dashboard-&-self-service).

### Saved lists / favourites {#saved-lists-/-favourites}

Allows users to save products, baskets or commonly ordered items for quick access and reorder later. 

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-PROD-010 | Restricted or customer-specific products shall not be exposed to unauthorised users. | Must |
| REQ-PROD-011 | Product visibility rules shall apply to listings, search, PDPs, saved lists, basket and checkout. | Must |
| REQ-PROD-013 | Eligible users shall be able to save or favourite products where account functionality allows. | Should |
| REQ-BASKET-005 | Basket persistence across sessions/devices shall be supported where agreed. | Should |
| REQ-BASKET-006 | Saved products/lists shall be revalidated when reused. | Must |
| REQ-ORDER-008 | Reorder functionality shall be supported where appropriate. | Should |

Further detail is covered in the sections on [Basket & Ordering](#basket-&-ordering), [Account Dashboard & Self-Service](#account-dashboard-&-self-service), and [Product Visibility & Restricted Products](#product-visibility-&-restricted-products).

### Order history / Invoices {#order-history-/-invoices}

Allows users linked to the same Europa customer code to view previous orders, order status and related billing documents.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-ORDER-005 | Account users shall be able to view order history where data is available. | Must |
| REQ-ORDER-006 | Users shall be able to view individual order details. | Must |
| REQ-ORDER-007 | Order status shall be displayed where available. | Must |
| REQ-ORDER-008 | Reorder functionality shall be supported where appropriate. | Should |
| REQ-ORDER-009 | Delivery tracking shall be linked where available. | Should |
| REQ-DASH-005 | Account users shall only see account data they are permitted to access. (all parent Europa Customer Code details) | Must |
| REQ-DOC-001 | Users shall be able to access invoices and related documents where permitted. | Must |
| REQ-SUPPORT-003 | Support or return requests shall link to relevant orders where possible. | Should |
| REQ-DEL-002 | Delivery tracking shall be displayed where tracking data is available. | Should |

Further detail is covered in the sections on [Orders & Order Processing](#orders-&-order-processing), [Account Dashboard & Self-Service](#account-dashboard-&-self-service), and [Documents, Downloads & Resources](#documents,-downloads-&-resources).

### Account Users / Permissions {#account-users-/-permissions}

Allows Europa account-level users or internal teams to manage multiple users associated with a customer account, subject to backend permissions.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-ACC-010 | Multiple users linked to one customer account shall be supported. | Must |
| REQ-SEC-006 | Key account/admin/security actions shall be auditable where appropriate. | Should |
| REQ-AUDIT-001 | Key admin, account, permission and security-related actions shall be logged where appropriate. | Should |
| REQ-AUDIT-002 | Audit requirements and retention periods shall be confirmed before implementation. | Should |

Further detail is covered in the sections on [Account Access & Customer Permissions](#account-access-&-customer-permissions), Role-Based Access, and [Security & Access Control](#security-&-access-control).

### Members dashboard {#members-dashboard}

Provides members with access to CPD content, training materials, progress information and member-only resources.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-AUTH-001 | Users shall be able to log in and log out securely. | Must |
| REQ-ACC-001 | Account access and customer permissions shall be enforced by the backend. | Must |
| REQ-DOC-005 | Protected or member-only downloads shall be restricted where required. | Should |
| REQ-CPD-001 | Members-only areas shall be protected and restricted to authorised members. | Must |
| REQ-CPD-002 | Members dashboard shall link to CPD courses, training materials and certificates. | Must |
| REQ-CPD-004 | Members area shall be clearly distinguished from the customer account/buying portal. | Must |
| REQ-CPD-003 | Member-specific progress or status shall be shown where available. | Should |
| REQ-CPD-009 | Progress or completion tracking shall be supported where in scope. | Should |
| REQ-RESP-003 | Account and members areas shall be usable on mobile devices. | Must |

Further detail is covered in the sections on [Members Area & CPD](#members-area-&-cpd), [Account Access & Customer Permissions](#account-access-&-customer-permissions), and [Authentication](#authentication).

### CPD Course Listing {#cpd-course-listing}

Displays available CPD courses, training modules or training materials for members to browse, search, filter and access.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-CPD-001 | Members-only areas shall be protected and restricted to authorised members. | Must |
| REQ-CPD-002 | Members dashboard shall link to CPD courses, training materials and certificates. | Must |
| REQ-CPD-004 | Members area shall be clearly distinguished from the customer account/buying portal. | Must |
| REQ-CPD-005 | Available CPD courses or training modules shall be displayed. | Must |
| REQ-SEARCH-005 | Search shall support non-product content such as resources, guides, articles and downloads. | Should |
| REQ-CPD-003 | Member-specific progress or status shall be shown where available. | Should |
| REQ-CPD-006 | CPD courses shall support browsing, categorisation or filtering where content volume requires it. | Should |

Further detail is covered in the sections on [Members Area & CPD](#members-area-&-cpd), [Documents, Downloads & Resources](#documents,-downloads-&-resources), and [Account Access & Customer Permissions](#account-access-&-customer-permissions).

### CPD Course Detail {#cpd-course-detail}

Allows members to view a specific CPD course, access content and understand completion requirements.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-DOC-005 | Protected or member-only downloads shall be restricted where required. | Should |
| REQ-CPD-001 | Members-only areas shall be protected and restricted to authorised members. | Must |
| REQ-CPD-007 | Course detail pages shall display course title, description and learning details. | Must |
| REQ-CPD-008 | Course detail pages shall provide access to relevant course materials. | Must |
| REQ-CPD-003 | Member-specific progress or status shall be shown where available. | Should |
| REQ-CPD-009 | Progress or completion tracking shall be supported where in scope. | Should |
| REQ-CPD-011 | Users shall be able to view, download or print earned certificates where supported. | Should |
| REQ-A11Y-008 | Captions or transcripts shall be provided for video content where available. | Should |

Further detail is covered in the sections on [Members Area & CPD](#members-area-&-cpd), [Documents, Downloads & Resources](#documents,-downloads-&-resources), and [Account Access & Customer Permissions](#account-access-&-customer-permissions).

### Certificates {#certificates}

Allows members to view, download or print certificates linked to completed CPD activities.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-DOC-005 | Protected or member-only downloads shall be restricted where required. | Should |
| REQ-CPD-001 | Members-only areas shall be protected and restricted to authorised members. | Must |
| REQ-CPD-010 | Certificates shall be restricted to the correct user/member. | Must |
| REQ-CPD-009 | Progress or completion tracking shall be supported where in scope. | Should |
| REQ-CPD-011 | Users shall be able to view, download or print earned certificates where supported. | Should |

Further detail is covered in the sections on [Members Area & CPD](#members-area-&-cpd), [Documents, Downloads & Resources](#documents,-downloads-&-resources), and [Security & Access Control](#security-&-access-control).

### Resource Hub {#resource-hub}

Provides a central area for users to browse and access resources such as guides, downloads, videos, articles and technical content.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-CMS-001 | The CMS shall allow approved users to create, edit and publish CMS-managed content. | Must |
| REQ-CMS-002 | The CMS shall support structured content types for pages, articles, resources, downloads, landing pages and navigation. | Must |
| REQ-CMS-005 | The CMS shall support media and document management for CMS-owned images, documents and downloads. | Must |
| REQ-DOC-006 | Lead capture before download shall be supported where required. | Could |
| REQ-SEARCH-008 | Search indexing shall account for product publication status, CMS updates and removed/unpublished content. | Must |
| REQ-DOC-003 | CMS-managed downloads shall be supported. | Must |
| REQ-SEARCH-005 | Search shall support non-product content such as resources, guides, articles and downloads. | Should |
| REQ-RES-001 | Resource hub shall provide a central area for guides, downloads, videos, articles and technical content. | Must |
| REQ-RES-002 | Users shall be able to browse resources by type or category. | Must |
| REQ-RES-004 | CMS users shall be able to manage resource content. | Must |
| REQ-RES-003 | Resource search/filtering shall be supported where content volume requires it. | Should |
| REQ-RES-005 | Related products, support links or further reading shall be supported where relevant. | Should |
| REQ-ANL-004 | Downloads, video engagement and resource interactions shall be tracked where required. | Should |
| REQ-A11Y-008 | Captions or transcripts shall be provided for video content where available. | Should |

Further detail is covered in the sections on [Documents, Downloads & Resources](#documents,-downloads-&-resources), [CMS and Content Model](#cms-and-content-model), and [Search and Filtering](#search-and-filtering).

### Article / Guide {#article-/-guide}

Displays editorial or educational content such as guides, technical articles, blog posts or knowledge content.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-CMS-001 | The CMS shall allow approved users to create, edit and publish CMS-managed content. | Must |
| REQ-CMS-002 | The CMS shall support structured content types for pages, articles, resources, downloads, landing pages and navigation. | Must |
| REQ-CMS-005 | The CMS shall support media and document management for CMS-owned images, documents and downloads. | Must |
| REQ-SEARCH-005 | Search shall support non-product content such as resources, guides, articles and downloads. | Should |
| REQ-RES-004 | CMS users shall be able to manage resource content. | Must |
| REQ-RES-006 | Structured article or guide content shall be displayed. | Must |
| REQ-SEO-001 | CMS users shall be able to manage page titles and meta descriptions. | Must |
| REQ-SEO-004 | Image alt text management shall be supported. | Must |
| REQ-RES-005 | Related products, support links or further reading shall be supported where relevant. | Should |
| REQ-RES-007 | Articles/guides shall support imagery, embedded media and related links. | Should |
| REQ-ANL-004 | Downloads, video engagement and resource interactions shall be tracked where required. | Should |
| REQ-A11Y-008 | Captions or transcripts shall be provided for video content where available. | Should |

Further detail is covered in the sections on [CMS and Content Model](#cms-and-content-model), [Documents, Downloads & Resources](#documents,-downloads-&-resources), and [SEO](#seo).

### Download Page {#download-page}

Allows users to access downloadable assets such as PDFs, catalogues, datasheets, guides or white papers.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-CMS-001 | The CMS shall allow approved users to create, edit and publish CMS-managed content. | Must |
| REQ-CMS-002 | The CMS shall support structured content types for pages, articles, resources, downloads, landing pages and navigation. | Must |
| REQ-CMS-005 | The CMS shall support media and document management for CMS-owned images, documents and downloads. | Must |
| REQ-DOC-006 | Lead capture before download shall be supported where required. | Could |
| REQ-PROD-004 | Product assets such as images and datasheets shall come from EPIM where EPIM owns them. | Must |
| REQ-DOC-003 | CMS-managed downloads shall be supported. | Must |
| REQ-DOC-004 | Product assets and datasheets shall be distinguished from CMS-managed downloads. | Must |
| REQ-DOC-005 | Protected or member-only downloads shall be restricted where required. | Should |
| REQ-SEARCH-005 | Search shall support non-product content such as resources, guides, articles and downloads. | Should |
| REQ-RES-004 | CMS users shall be able to manage resource content. | Must |
| REQ-RES-008 | Download pages shall display title, description and file details. | Must |
| REQ-RES-009 | Users shall be able to download the relevant asset. | Must |
| REQ-FORM-001 | Reusable form components shall be provided. | Must |
| REQ-FORM-002 | Contact, support, registration, returns, newsletter and download/lead capture forms shall be supported where required, acting as a proxy to exising europa mail flows | Must |
| REQ-FORM-004 | Forms shall provide clear validation, success and failure states. | Must |
| REQ-FORM-005 | Forms shall include spam/bot protection. | Must |
| REQ-SEO-001 | CMS users shall be able to manage page titles and meta descriptions. | Must |
| REQ-ANL-003 | Form submissions and lead capture interactions shall be tracked. | Must |
| REQ-PRIV-005 | Consent wording shall be clear where forms capture consent. | Must |
| REQ-ANL-004 | Downloads, video engagement and resource interactions shall be tracked where required. | Should |

Further detail is covered in the sections on Documents, Downloads & Resources, Forms, Enquiries & Support, and CMS and Content Model.

### Contact / Support {#contact-/-support}

Provides users with a clear route to contact Europa, get support, raise enquiries or access self-service help. Forms include external team visit, catalogue request amongst others, all support routes will feed Europa’s existing email workflows.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-SUPPORT-001 | Users shall be able to raise support enquiries from relevant areas of the site, proxied to existing Europa mail flows | Must |
| REQ-SUPPORT-005 | Support enquiries shall route to the correct internal support process. | Must |
| REQ-SUPPORT-006 | Live chat and support contact options where agreed. | Should |
| REQ-SUPPORT-007 | Fallback contact routes shall be provided when live chat is unavailable. | Must |
| REQ-FORM-001 | Reusable form components shall be provided. | Must |
| REQ-FORM-002 | Contact, support, registration, returns, newsletter and download/lead capture forms shall be supported where required, acting as a proxy to exising europa mail flows | Must |
| REQ-FORM-003 | Forms shall validate required fields and input formats on both client and server side. | Must |
| REQ-FORM-004 | Forms shall provide clear validation, success and failure states. | Must |
| REQ-FORM-005 | Forms shall include spam/bot protection. | Must |
| REQ-FORM-006 | Forms shall comply with data protection and consent requirements. | Must |
| REQ-ANL-003 | Form submissions and lead capture interactions shall be tracked. | Must |
| REQ-FORM-008 | Conditional fields and dynamic form behaviour shall be supported where required. | Should |
| REQ-INT-004 | live chat integration shall be implemented. Support requests should hit existing Europa support mail flows, via ui form proxy. | Should |
| REQ-ERR-001 | The website shall provide clear user-facing error states for failed API requests, unavailable data, failed form submissions and failed order actions. | Must |

Further detail is covered in the sections on [Forms, Enquiries & Support](#forms,-enquiries-&-support), [Live Chat / Support Integration](#live-chat-/-support-integration), and [Analytics & Tracking](#analytics-&-tracking).

### Page Builder Page {#page-builder-page}

Provides a flexible CMS-managed template for content-led pages that do not require unique functional logic.

The page builder should enable approved users to create structured pages using predefined components, while maintaining consistency, responsiveness and performance across the site.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-CMS-001 | The CMS shall allow approved users to create, edit and publish CMS-managed content. | Must |
| REQ-CMS-002 | The CMS shall support structured content types for pages, articles, resources, downloads, landing pages and navigation. | Must |
| REQ-CMS-003 | CMS-managed content shall remain separate from EPIM product data and Syspro pricing/account/order data. | Must |
| REQ-CMS-004 | The CMS shall expose content via API for frontend rendering. | Must |
| REQ-CMS-005 | The CMS shall support media and document management for CMS-owned images, documents and downloads. | Must |
| REQ-PB-001 | The page builder shall allow approved users to create flexible content-led pages using predefined components. | Must |
| REQ-PB-002 | The page builder shall provide reusable components such as hero, text, media, CTAs, grids, banners, embeds and forms. | Must |
| REQ-PB-003 | Editors shall be able to add, remove and reorder page builder components. | Must |
| REQ-PB-004 | Page builder components shall maintain controlled layouts, styling and design consistency. | Must |
| REQ-PB-005 | Page builder content shall not override product, pricing, stock, account or transactional data. | Must |
| REQ-PB-006 | Page builder components shall be responsive and accessible across supported devices. | Must |
| REQ-PB-007 | Page builder content shall be delivered through API for frontend rendering. | Must |
| REQ-PB-008 | The component library shall be extendable without breaking existing pages. | Must |
| REQ-CMS-007 | The CMS shall support draft, preview and publish workflows where required. | Should |
| REQ-CMS-008 | The CMS shall support revision history or content versioning where required. | Should |

Further detail is covered in the sections on [Page Builder](#page-builder), [CMS and Content Model](#cms-and-content-model), [CMS Editing](#cms-editing), and [SEO](#seo-1)

# Cross-site functional requirements {#cross-site-functional-requirements}

Functionality that applies across multiple areas of the site, rather than being tied to a specific page or template.

### Search and filtering {#search-and-filtering}

Search will be a core part of the website experience and should support users looking for products, technical content, downloads, news, training material and support information.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-PROD-007 | Product filtering shall be driven by structured attributes rather than free-text parsing or manually configured filters. | Must |
| REQ-PROD-008 | Category-specific filter sets shall be supported. | Must |
| REQ-PROD-009 | Product listing and search pages shall allow sorting and refinement. | Must |
| REQ-SEARCH-001 | Site-wide search shall be accessible from the main navigation. | Must |
| REQ-SEARCH-002 | Product search shall support SKU, product name, description, category and brand where data allows. | Must |
| REQ-SEARCH-003 | Product search results shall default to relevance-based sorting. | Must |
| REQ-SEARCH-004 | Search result pages shall provide relevant filters. | Must |
| REQ-SEARCH-007 | Search results shall respect account permissions, buying access and product visibility rules. | Must |
| REQ-SEARCH-008 | Search indexing shall account for product publication status, CMS updates and removed/unpublished content. | Must |
| REQ-SEARCH-005 | Search shall support non-product content such as resources, guides, articles and downloads. | Should |
| REQ-RES-003 | Resource search/filtering shall be supported where content volume requires it. | Should |

Search behaviour should be consistent across desktop and mobile. Where a user is logged in, search results should respect their account permissions, product visibility rules and buying access.

Further technical detail is covered in the sections on Search Behaviour, Product Attributes, Taxonomy & Filtering, and Product Visibility & Restricted Products.

### Navigation {#navigation}

The website navigation should make it easy for different user types to reach the correct area of the site without needing to understand Europa’s internal structure.

Navigation should support product discovery, account access, members content, support journeys and CMS-managed content.

Shared navigation and page-structure components should be used consistently across the site, unless a specific page template requires a different treatment.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-NAV-001 | The site shall provide clear routes into products, account access, resources, services and support. | Must |
| REQ-NAV-002 | The site shall provide a clear primary navigation structure accessible across all pages. | Must |
| REQ-NAV-003 | Navigation shall provide quick access to search, account, basket and support. | Must |

Further technical detail is covered in the sections on [CMS and Content Model](#cms-and-content-model), [Page Builder](#page-builder), and [Accessibility](#accessibility-1).

### Forms {#forms}

Forms will be used across the website for contact, support, account registration, content downloads, newsletter sign-up, potential lead capture, visit requests, catalogue requests, customer surveys, NPS capture and on-site questionnaires.

Forms should be consistent, secure and easy to complete across devices, while ensuring data quality and compliance with privacy requirements. Forms should prepopulate known customer/account/order data where possible.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-DOC-006 | Lead capture before download shall be supported where required. | Could |
| REQ-FORM-001 | Reusable form components shall be provided. | Must |
| REQ-FORM-002 | Contact, support, registration, returns, newsletter and download/lead capture forms shall be supported where required, acting as a proxy to existing europa mail flows | Must |
| REQ-FORM-003 | Forms shall validate required fields and input formats on both client and server side. | Must |
| REQ-FORM-004 | Forms shall provide clear validation, success and failure states. | Must |
| REQ-FORM-005 | Forms shall include spam/bot protection. | Must |
| REQ-FORM-006 | Forms shall comply with data protection and consent requirements. | Must |
| REQ-FORM-007 | Forms shall be responsive and accessible across devices. | Must |
| REQ-FORM-008 | Conditional fields and dynamic form behaviour shall be supported where required. | Should |

Further technical detail is covered in the sections on [Forms, Enquiries & Support](#forms,-enquiries-&-support), [Security & Access Control](#security-&-access-control), and [Data Quality & Validation](#data-quality-&-validation).

### CMS Editing {#cms-editing}

The CMS should allow approved Europa users to manage website content without requiring developer involvement for routine updates.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-CMS-001 | The CMS shall allow approved users to create, edit and publish CMS-managed content. | Must |
| REQ-CMS-002 | The CMS shall support structured content types for pages, articles, resources, downloads, landing pages and navigation. | Must |
| REQ-CMS-003 | CMS-managed content shall remain separate from EPIM product data and Syspro pricing/account/order data. | Must |
| REQ-CMS-004 | The CMS shall expose content via API for frontend rendering. | Must |
| REQ-CMS-005 | The CMS shall support media and document management for CMS-owned images, documents and downloads. | Must |
| REQ-CMS-006 | CMS access shall be restricted by user role and permission level. | Must |
| REQ-PB-001 | The page builder shall allow approved users to create flexible content-led pages using predefined components. | Must |
| REQ-PB-003 | Editors shall be able to add, remove and reorder page builder components. | Must |
| REQ-CMS-007 | The CMS shall support draft, preview and publish workflows where required. | Should |
| REQ-CMS-008 | The CMS shall support revision history or content versioning where required. | Should |
| REQ-ADMIN-004 | Publishing rights may be restricted to senior editors/admins. | Should |

### 

### CMS {#cms}

The CMS will manage structured content, page composition and non-product content, while integrating with frontend and backend systems. 

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-CMS-001 | The CMS shall allow approved users to create, edit and publish CMS-managed content. | Must |
| REQ-CMS-002 | The CMS shall support structured content types for pages, articles, resources, downloads, landing pages and navigation. | Must |
| REQ-CMS-003 | CMS-managed content shall remain separate from EPIM product data and Syspro pricing/account/order data. | Must |

### SEO {#seo}

The website should be built with strong SEO foundations so that product, category, resource and content pages can be discovered effectively by search engines.

SEO requirements apply across both functional templates and CMS-managed pages.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-SEO-001 | CMS users shall be able to manage page titles and meta descriptions. | Must |
| REQ-SEO-002 | URL structures shall be clean, readable and consistent. | Must |
| REQ-SEO-003 | Templates shall generate appropriate heading structure. | Must |
| REQ-SEO-004 | Image alt text management shall be supported. | Must |
| REQ-SEO-005 | XML sitemap and robots.txt generation shall be supported. | Must |
| REQ-SEO-006 | Redirects from old URLs shall be supported where content is migrated. | Must |
| REQ-SEO-007 | SEO-friendly category and landing page content shall be supported. | Must |
| REQ-SEO-008 | Internal linking shall support crawlability and discoverability. | Must |
| REQ-ANL-005 | Account registration and login journey performance shall be tracked where required. | Should |
| REQ-ANL-007 | Analytics shall respect cookie consent and privacy preferences. | Must |
| REQ-ANL-004 | Downloads, video engagement and resource interactions shall be tracked where required. | Should |
| REQ-ANL-006 | CTA interactions shall be tracked where required. | Should |

Further technical detail is covered in the sections on [CMS and Content Model](#cms-and-content-model), [Page Builder](#page-builder), and [Admin Access & Permissions](#admin-access-&-permissions).

### Analytics {#analytics}

Analytics should provide insight into user behaviour, journeys and performance across the website, while respecting privacy and consent requirements. First-party questionnaire capture will be used to facilitate recurring annual customer surveys for logged-in users.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-ANL-001 | Analytics tracking shall be implemented across the website. i.e. posthog | Must |
| REQ-ANL-002 | Search, product views, basket and checkout journeys shall be tracked. | Must |
| REQ-ANL-003 | Form submissions and lead capture interactions shall be tracked. | Must |
| REQ-ANL-005 | Account registration and login journey performance shall be tracked where required. | Should |
| REQ-ANL-007 | Analytics shall respect cookie consent and privacy preferences. | Must |
| REQ-ANL-004 | Downloads, video engagement and resource interactions shall be tracked where required. | Should |
| REQ-ANL-006 | CTA interactions shall be tracked where required. | Should |

Further technical detail is covered in the sections on [Analytics & Tracking](#analytics-&-tracking), [Security & Access Control](#security-&-access-control), and Cookie Consent / Privacy where applicable.

### Accessibility {#accessibility}

The website should be accessible across key user journeys, devices and assistive technologies, aligning with recognised accessibility standards..

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-NAV-007 | Navigation shall be accessible via keyboard and screen readers. | Must |
| REQ-A11Y-001 | Key templates and journeys shall meet WCAG 2.2 AA expectations. | Must |
| REQ-A11Y-002 | Semantic HTML structure shall be used. | Must |
| REQ-A11Y-003 | Keyboard navigation shall be supported. | Must |
| REQ-A11Y-004 | Colour contrast shall meet accessibility requirements. | Must |
| REQ-A11Y-005 | Forms shall include clear labels and error messages. | Must |
| REQ-A11Y-006 | Images and media shall include appropriate alternative text. | Must |
| REQ-A11Y-007 | Interactive components shall be usable with assistive technology. | Must |
| REQ-A11Y-008 | Captions or transcripts shall be provided for video content where available. | Should |

Further technical detail is covered in the [Accessibility](#accessibility-1) section.

### Responsiveness {#responsiveness}

The website should work consistently across desktop, tablet and mobile devices, with no loss of critical functionality on smaller screens.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-PB-006 | Page builder components shall be responsive and accessible across supported devices. | Must |
| REQ-NAV-004 | Navigation shall support desktop, tablet and mobile patterns. | Must |
| REQ-FORM-007 | Forms shall be responsive and accessible across devices. | Must |
| REQ-RESP-001 | All pages shall work across desktop, tablet and mobile. | Must |
| REQ-RESP-002 | Product browsing, filters, basket and checkout shall be mobile-friendly. | Must |
| REQ-RESP-003 | Account and members areas shall be usable on mobile devices. | Must |
| REQ-RESP-004 | Forms, images and media shall scale appropriately across devices. | Must |

Further technical detail is covered in the sections on [Accessibility](#accessibility-1), [Performance](#performance-1), and [Environments, Testing & Deployment](#environments,-testing-&-deployment).

### Performance {#performance}

The website should be fast, stable and responsive across devices, connection types and user journeys.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-ARCH-005 | A cached data layer shall be used where appropriate to support performance, search, product listing and pricing-support data. | Must |
| REQ-PERF-001 | Images and media assets shall be optimised before storing. | Must |
| REQ-PERF-002 | Key templates shall have fast page load times. | Must |
| REQ-PERF-003 | Frontend assets such as JS, CSS and images shall be optimised before serving. | Must |
| REQ-PERF-004 | Content and API caching strategies shall be implemented where appropriate. | Must |
| REQ-PERF-005 | Product lists and filtered results shall remain performant at scale. | Must |
| REQ-PERF-006 | Login, basket and checkout shall remain reliable under normal traffic loads. | Must |

Further technical detail is covered in the [Performance](#performance-1) section, with supporting context in [Architecture Overview](#architecture-overview) and [Synchronisation Strategy](#synchronisation-strategy).

### Authentication {#authentication}

Authentication covers how users login, register, reset password and access protected areas of the website.

The authentication experience should be secure, clear and easy to follow.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-AUTH-001 | Users shall be able to log in and log out securely. | Must |
| REQ-AUTH-002 | Registration shall be supported as per the current flow. | Must |
| REQ-AUTH-003 | Forgotten password and reset password journeys shall be supported. | Must |
| REQ-AUTH-004 | Password reset shall use secure reset instructions and valid reset links. | Must |
| REQ-AUTH-005 | Password policy requirements shall be enforced. | Must |
| REQ-AUTH-006 | Password reset shall avoid exposing whether an account exists. | Must |
| REQ-AUTH-007 | Email verification shall be supported where required. | Should |
| REQ-AUTH-008 | Expired or invalid reset/verification links shall be handled clearly. | Must |
| REQ-AUTH-009 | Secure session handling shall be supported. | Must |

Further technical detail is covered in the sections on [Account Access & Customer Permissions](#account-access-&-customer-permissions), [Account Onboarding & Approval](#account-onboarding-&-approval), and [Security & Access Control](#security-&-access-control).

### Role-Based Access {#role-based-access}

The website will need to support different user roles and permissions across account, purchasing, members and administration areas.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-CMS-006 | CMS access shall be restricted by user role and permission level. | Must |
| REQ-NAV-005 | Navigation items may vary based on login state, role or permissions. | Must |
| REQ-PROD-010 | Restricted or customer-specific products shall not be exposed to unauthorised users. | Must |
| REQ-PROD-011 | Product visibility rules shall apply to listings, search, PDPs, saved lists, basket and checkout. | Must |
| REQ-CHECKOUT-001 | Checkout shall be restricted to authorised users with approved purchasing access. | Must |
| REQ-ACC-001 | Account access and customer permissions shall be enforced by the backend. | Must |
| REQ-ACC-002 | Purchasing access shall be restricted until approval/permissions allow. | Must |
| REQ-ACC-010 | Multiple users linked to one customer account shall be supported. | Must |
| REQ-ACC-011 | Different permission levels for account users shall be supported where required. | Must |
| REQ-DASH-004 | Dashboard shall respect user role, customer account and permission rules. | Must |
| REQ-DASH-005 | Account users shall only see account data they are permitted to access. (all parent Europa Customer Code details) | Must |
| REQ-CPD-001 | Members-only areas shall be protected and restricted to authorised members. | Must |
| REQ-SEC-002 | The backend shall enforce permissions before returning protected data or allowing protected actions. | Must |

### Notifications {#notifications}

Notifications will be used to support account journeys, abandoned baskets and system messages. Notifications for orders or existing upstream processes are not supported.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-AUTH-004 | Password reset shall use secure reset instructions and valid reset links. | Must |
| REQ-AUTH-007 | Email verification shall be supported where required. | Should |
| REQ-AUTH-008 | Expired or invalid reset/verification links shall be handled clearly. | Must |
| REQ-ACC-005 | The registration flow shall explain the approval or verification process clearly. | Must |
| REQ-ACC-007 | Pending users shall be shown clear account status messaging. | Must |
| REQ-ACC-008 | Rejected/unverified users shall be given clear messaging and a support route. | Must |
| REQ-DASH-003 | Dashboard shall display relevant account status, notifications or messages where available. | Should |

Further technical detail is covered in the sections on [Account Dashboard & Self-Service](#account-dashboard-&-self-service), [Orders & Order Processing](#orders-&-order-processing), and [Members Area & CPD](#members-area-&-cpd).

### Cookie Consent and Privacy {#cookie-consent-and-privacy}

The website must support appropriate cookie consent, privacy controls and data protection expectations.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-FORM-006 | Forms shall comply with data protection and consent requirements. | Must |
| REQ-ANL-007 | Analytics shall respect cookie consent and privacy preferences. | Must |
| REQ-PRIV-001 | A cookie consent mechanism shall be provided. | Must |
| REQ-PRIV-002 | Users shall be able to accept, reject or manage cookie preferences. | Must |
| REQ-PRIV-003 | Non-essential tracking shall be blocked until consent is provided where required. | Must |
| REQ-PRIV-004 | Privacy and cookie policy links shall be provided. | Must |
| REQ-PRIV-005 | Consent wording shall be clear where forms capture consent. | Must |

Further technical detail is covered in the sections on [Security & Access Control](#security-&-access-control) and [Analytics & Tracking](#analytics-&-tracking).

### Live Chat and Support {#live-chat-and-support}

Live chat and support functionality should help users get assistance without disrupting core browsing and ordering journeys.

| ID | Requirement | Priority |
| :---- | :---- | :---- |
| REQ-SUPPORT-001 | Users shall be able to raise support enquiries from relevant areas of the site, proxied to existing Europa mail flows | Must |
| REQ-SUPPORT-002 | Users shall be able to submit return-related requests via ui, triggering returns email to Europa | Should |
| REQ-SUPPORT-003 | Support or return requests shall link to relevant orders where possible. | Should |
| REQ-SUPPORT-004 | Support messages and return information shall be restricted to authorised users. | Must |
| REQ-SUPPORT-005 | Support enquiries shall route to the correct internal support process. | Must |
| REQ-SUPPORT-006 | Live chat and support contact options where agreed. | Should |
| REQ-SUPPORT-007 | Fallback contact routes shall be provided when live chat is unavailable. | Must |
| REQ-INT-004 | live chat integration shall be implemented. Support requests should hit existing Europa support mail flows, via ui form proxy. | Should |

Further technical detail is covered in the sections on [Live Chat / Support Integration](#live-chat-/-support-integration) and [Forms, Enquiries & Support](#forms,-enquiries-&-support).

# Supporting technical detail {#supporting-technical-detail}

## Architecture Overview {#architecture-overview}

The proposed website will act as a customer-facing digital platform and presentation layer, consuming structured data from upstream systems rather than becoming the source of truth for product, pricing, stock or customer account data.

The frontend and CMS shall be decoupled. The CMS will operate as a headless content source for editable marketing, editorial and page-builder content, exposing structured content via API for frontend consumption.

The customer-facing frontend will render CMS-managed content, EPIM product data and Syspro/backend data through agreed APIs and backend services rather than being tightly coupled to the CMS.

Laravel backend services will act as the orchestration layer for account, basket, checkout, pricing, search and integration logic. The frontend should not connect directly to Syspro or make independent decisions about pricing, purchasing eligibility, stock, customer permissions or restricted product visibility.

Where required for SEO, performance or crawlability, key public-facing pages may be rendered as pre-rendered, server-rendered or cached HTML. This should apply where appropriate to product, category, CMS-managed and landing pages so that core content is available to search engines without relying solely on client-side rendering. Caching will be disabled for authenticated users.

The high-level architecture is expected to include:

* A customer-facing website frontend.  
* A CMS for editable marketing, editorial and page builder content.  
* Laravel backend services for account, basket, checkout, pricing, search and integration logic.  
* EPIM as the source of truth for product data.  
* Syspro as the source of truth for pricing, customers, orders, stock and account-related data, with SQL access available for required data reads.  
* A cached data layer to support performance, resilience, search, product listing and pricing lookups.  
* Third-party services for analytics, live chat/support, email and delivery tracking where required.

The website should maintain a clear separation between:

* CMS-managed content  
* Product data from EPIM  
* Pricing, stock and customer/account data from Syspro  
* Transactional flows such as basket, checkout and order submission  
* Member/CPD content and access-controlled resources

The website should not rely on frontend logic for pricing, purchasing eligibility or customer-specific visibility. These behaviours should be handled by backend services using data retrieved from EPIM, Syspro SQL access, the cached data layer and any agreed integration services.

## CMS and Content Model {#cms-and-content-model}

The CMS will manage structured website content, page composition and non-transactional content. It should provide editors with enough flexibility to update routine content without developer support, while keeping layouts, data ownership and functionality controlled.

Key requirements:

* Support structured content types for pages, articles, resources, downloads, landing pages and navigation.  
* Support a component-based page builder using predefined, approved content blocks.  
* Ensure each content block has a clear schema, validation rules and controlled layout options.  
* Allow editors to create, edit and publish CMS-managed content.  
* Manage media and document assets such as images, PDFs and downloads.  
* Support SEO fields including page title, meta description.  
* Maintain clear separation between CMS-managed content and product, pricing, stock, account or transactional data.  
* Expose content in a predictable structure for the frontend to consume.  
* Support content caching and appropriate cache invalidation when content is updated.  
* Restrict CMS access and editing permissions based on user roles.

The CMS should support flexible content management while preventing unsupported layouts, inconsistent presentation or changes to data owned by other systems.

## Page Builder {#page-builder}

The page builder will use a component-based content model within the CMS, allowing editors to construct pages from predefined content blocks rather than creating custom layouts.

Content will be structured as an ordered set of components, each with defined fields and configuration options. This content will be exposed via API and rendered dynamically by the frontend (Vue application).

Implementation Approach

* Flexible content structure (e.g. ACF) used to define pages as a sequence of components  
* Each CMS component maps directly to a Vue component  
* Content is delivered via API and rendered on the frontend


Component Structure

* Each component has a defined schema (fields and validation rules)  
* Components are reusable and centrally managed  
* New components can be added without affecting existing pages

Constraints

* Layout and styling are controlled through predefined component options  
* Freeform or unstructured content is not supported  
* Editors cannot override core layout or functional behaviour  
* Page builder content cannot override product, pricing or account data

Performance & Integration

* Content is optimised for API delivery and frontend rendering  
* Caching should be applied where appropriate  
* Media should be optimised and delivered via CDN

## Product Data & EPIM {#product-data-&-epim}

EPIM should remain the source of truth for product information used by the website.

Product data consumed by the website includes:

| Data Area |  |
| :---: | :---: |
| Core product data | SKU, product name, short description, long description |
| Product taxonomy | Category, subcategory, brand, range |
| Attributes | Technical specifications, dimensions, colour, size, compatibility |
| Product media | Images, diagrams, videos |
| Product documents | Datasheets, manuals, certificates, guides |
| Product status | Active, inactive, restricted, discontinued |
| Related products | Alternatives, accessories, recommended products |
| Search data | Keywords, synonyms, searchable attributes |

Product data should be synchronised into the cached data layer for frontend display, search indexing, filtering and product listing performance.

The website should not allow product data to be edited directly in the CMS unless the field is explicitly identified as CMS-owned supporting content.

## Product Attributes, Taxonomy & Filtering {#product-attributes,-taxonomy-&-filtering}

Product attributes, taxonomy and filtering should be driven by structured product data from EPIM.

EPIM is expected to act as the source of truth for product master data, including product descriptions, technical data, assets, categories and structured attributes. Product data should be consumed by the website via the backend and cached data layer, rather than recreated or maintained in the CMS.

#### Product Attributes {#product-attributes}

Product attributes should utilise structured EPIM data, including ETIM / EDATA fields where available.

These attributes are expected to support:

* Structured specification display on product detail pages  
* Category-specific filtering on listing pages  
* Refinement of product search results  
* Potential linkage between products and related technical content

The website should not rely on parsing free-text descriptions or manually configured filters where structured attribute data is available.

#### Taxonomy and Categories {#taxonomy-and-categories}

Product attributes should utilise structured EPIM data, including ETIM / EDATA fields where available.

These attributes are expected to support:

* Structured specification display on product detail pages  
* Category-specific filtering on listing pages  
* Refinement of product search results  
* Potential linkage between products and related technical content

The website should not rely on parsing free-text descriptions or manually configured filters where structured attribute data is available.

#### Filtering Strategy {#filtering-strategy}

Filtering should be dynamically generated from structured EPIM attributes and should vary based on the product category or result set.

Filtering should support:

* Category-specific filter sets  
* Attribute-driven filtering (not manual or CMS-defined)  
* Class-specific filters based on product type  
* Multi-select filtering  
* Sorting and refinement of product lists  
* Mobile-friendly filter interaction  
* Enforcement of product visibility rules (no exposure of restricted products)

Typical filter attributes may include technical fields such as dimensions, ratings, material or classification attributes, depending on EPIM data.

#### Data Handling {#data-handling}

The backend should ingest and normalise EPIM product, category and attribute data into a cached data/search layer.

The frontend should consume filter options and product listings via API and should not determine filter logic itself.

Where EPIM data is incomplete or inconsistent, the system should degrade gracefully and surface issues for validation rather than failing or exposing incorrect results.

## Search Behaviour {#search-behaviour}

Search should support discovery across both product and non-product content, while respecting product visibility, account permissions and structured data ownership.

Product search should be driven by EPIM data, while non-product content should be sourced from CMS or other content systems.

#### Search Scope {#search-scope}

* Products (EPIM data)  
* Product categories (taxonomy)  
* Product attributes/specifications  
* Resources, guides and articles (CMS)  
* Downloads and documents  
* CPD/training content  
* Support content and FAQs

#### Product search behaviour {#product-search-behaviour}

Product search should operate on indexed EPIM data and support:

* SKU / product code search  
* Product name search  
* Description-based matching where relevant  
* Category and product group matching  
* Brand/manufacturer search where data is available  
* Attribute-informed relevance where applicable  
* Default relevance-based sorting  
* Filter refinement on result sets

Search results must respect account permissions and product visibility rules before being returned to the frontend.

#### Synonyms and equivalent terms {#synonyms-and-equivalent-terms}

Search should support synonym and equivalent-term handling to improve findability.

This may include:

* Alternative product terminology  
* Industry-specific naming variations  
* Abbreviations  
* Common misspellings or variants

#### Search indexing and data flow {#search-indexing-and-data-flow}

Search indexing should be handled by the backend/search layer using EPIM and CMS data.

Expected flow:  
EPIM \+ CMS data → backend/cached layer → search index → frontend query → filtered, permission-aware results

The frontend should not perform and search logic independently.

Indexing should account for:

* Product availability and publication status  
* Product visibility and account permissions  
* Category and attribute updates from EPIM  
* CMS content updates  
* Removal of unpublished or deleted content

## Product Visibility & Restricted Products {#product-visibility-&-restricted-products}

This section defines how the website determines whether a product can be shown, priced, added to basket or purchased by a given user.

Product visibility and purchasing eligibility must be controlled by backend services using EPIM, Syspro, customer/account data and cached data sources. The frontend may adapt what is shown, but must not independently decide whether a product is visible, restricted, purchasable or priced.

Visibility rules apply across listings, search, product detail pages, saved lists, basket and checkout. These rules should account for publication status, discontinued products, partial-hold and full-hold statuses, restricted products, customer-specific products, account permissions and buying access.

Where a product is visible but affected by availability, restriction or hold status, the website should provide clear customer-facing messaging and prevent purchase where the product is not purchasable.

### Pricing flow {#pricing-flow}

Pricing should be handled by the backend and should not be calculated in the frontend.

When a price is required, the frontend should send the required product and basket context to the Laravel backend. The backend should then resolve the applicable pricing using the pricing engine and the relevant synchronised Syspro data.

A typical price request may include:

* Customer/account identifier  
* Stock code/SKU  
* Quantity  
* Date  
* Currency where applicable  
* Other customer context required for pricing

The expected pricing flow is: Frontend price request, Laravel backend, pricing engine, cached pricing/customer/product data, calculated price, frontend display

The pricing engine should resolve pricing according to the agreed hierarchy and rules, including contract pricing, standard pricing, discounts, quantity breaks, promotions and currency where applicable.

The frontend should only display the calculated result and any supporting pricing message where applicable.

### Product hold statuses {#product-hold-statuses}

The website shall consume and respect product hold-status data where available. Product hold statuses shall be handled differently depending on whether the product is on partial hold or full hold.

A product on partial hold is being discontinued but still has remaining stock available. These products may remain visible and purchasable while stock exists, but the website should clearly tell customers that availability is limited and that the product will no longer be available once remaining stock has sold through.

A product on full hold has sold out and will not be sold again. These products should not be purchasable. Where the product page remains accessible, the website should clearly tell customers that the product is unavailable or discontinued.

### Syspro ERP flow {#syspro-erp-flow}

Syspro ERP is expected to remain the source of truth for pricing, customers, stock, account status and order-related data.

Data from Syspro will be made available to the website through Data Switch and/or scheduled exports, with the exact integration method to be confirmed.

The architecture should allow the Laravel backend orchestration layer and cached data layer to consume Syspro-originating data, without requiring the frontend to connect directly to Syspro.

Syspro-related data is expected to support a number of key website functions, including pricing, customer access, product visibility, stock, ordering and account-related features.

The following provides a summary of which areas are confirmed within the supplied pricing documentation, and which require further validation.

| Area | Confirmed Source from Supplied Pricing Document |
| :---- | :---- |
| Customer account status | Requires confirmation. Not named in supplied pricing document |
| Web access permissions | Requires confirmation. Web access toggle discussed in discovery, but SQL field name not supplied |
| Customer price groups | dbo.ArCustomer.PriceGroup, dbo.SorPriceGroup, dbo.SorPriceGroupRules.PriceGroup |
| Contract pricing | dbo.ArCustomer.BuyingGroup1–5, dbo.SorContractPrice.CustomerBuyGrp, dbo.SorContractPrice.StockCode, dbo.SorContractPrice.PriceMethod, dbo.SorContractPrice.FixedPrice, dbo.SorContractPrice.StartDate, dbo.SorContractPrice.ExpiryDate |
| Standard pricing | dbo.ArCustomer.Customer, dbo.ArCustomer.PriceGroup, dbo.SorPriceGroupRules.PriceGroup, dbo.SorPriceGroupRules.PriceList, dbo.SorPriceGroupRules.Priority, dbo.SorPriceGroupRules.StartDate, dbo.SorPriceGroupRules.ClosingDate, dbo.SorPriceListDetail.StockCode, dbo.SorPriceListDetail.PriceList, dbo.SorPriceListDetail.Price, dbo.SorPriceListDetail.DiscPct1 |
| Quantity discount logic | dbo.SorPriceListDetail.ThresholdQty1–4, dbo.SorPriceListDetail.QdbPrice1–4, dbo.SorPriceListDetail.QdbDiscount1–4, dbo.SorPriceListDetail.BasisPriceList; contract QDB: dbo.SorConQtyDiscBrk.QtyBreak, dbo.SorConQtyDiscBrk.QtyPrice, dbo.InvPrice.SellingPrice |
| Stock and availability | Not yet confirmed. dbo.InvMaster.StockCode is referenced for joins, but stock quantity/availability fields are not defined |
| Order submission | Not yet confirmed. Current discovery confirms website orders are submitted to Syspro through the agreed backend/Data Switch flow, but no SQL tables or final file fields have been confirmed. Requires sample web orders, Data Switch export/import examples and sandbox validation. |
| Order history | Not yet confirmed. Business requirement confirmed for customer-code-level order visibility, including non-website order sources. Requires confirmation of order header/line tables, customer code field, order number, order status, order date, order value, delivery/tracking reference and source/channel fields where available. |
| Invoice / document access | Not yet confirmed. Business requirement confirmed for authorised users to view invoices/account documents linked to the customer code. Requires confirmation of invoice/document tables or document system source, customer code mapping, invoice number, invoice date, due date, paid status, total amount, document URL/file reference and permission fields where available. |
| Customer-specific product rules | Partially confirmed via price list behaviour (e.g. restricted SKUs tied to specific price lists). Relevant fields: dbo.SorPriceListDetail.PriceList, dbo.SorPriceListDetail.StockCode |

To support the above, the architecture should allow required Syspro data to be queried, transformed and cached in a controlled way so the website can operate efficiently without placing unnecessary load on Syspro.

Where data is needed frequently by the website, such as pricing-support data, account permissions, product visibility rules or stock indicators, it should be made available to the backend through a cached data layer using agreed synchronisation or refresh patterns from Syspro SQL.

### Syspro SQL Data Mapping (Pricing & Customer Context) {#syspro-sql-data-mapping-(pricing-&-customer-context)}

The following section provides a more detailed mapping of how Syspro data structures align to website and backend requirements, based on the supplied pricing documentation.

| Website / Backend Requirement | Confirmed Syspro Table(s) | Confirmed Column(s) |
| :---- | :---- | :---- |
| Customer identifier | dbo.ArCustomer | Customer |
| Customer price group | dbo.ArCustomer, dbo.SorPriceGroup, dbo.SorPriceGroupRules | ArCustomer.PriceGroup, SorPriceGroupRules.PriceGroup |
| Standard pricing | dbo.ArCustomer, dbo.SorPriceGroupRules, dbo.SorPriceListDetail, dbo.InvMaster | ArCustomer.Customer, ArCustomer.PriceGroup, SorPriceGroupRules.PriceGroup, SorPriceGroupRules.PriceList, SorPriceGroupRules.Priority, SorPriceGroupRules.StartDate, SorPriceGroupRules.ClosingDate, SorPriceListDetail.StockCode, SorPriceListDetail.PriceList, SorPriceListDetail.Price, SorPriceListDetail.DiscPct1, InvMaster.StockCode |
| Trade/base price | dbo.SorPriceListDetail | StockCode, PriceList, Price |
| Discount percentage | dbo.SorPriceListDetail | DiscPct1 |
| Price rule priority | dbo.SorPriceGroupRules | Priority |
| Price rule dates | dbo.SorPriceGroupRules | StartDate, ClosingDate |
| Flat pricing | dbo.SorPriceListDetail | PriceList, Price, DiscPct1 |
| Quantity breaks (flat) | dbo.SorPriceListDetail | ThresholdQty1–4, QdbPrice1–4 |
| Quantity breaks (percentage) | dbo.SorPriceListDetail | BasisPriceList, ThresholdQty1–4, QdbDiscount1–4, Price |
| Contract pricing (customer context) | dbo.ArCustomer | Customer, CustomerClass, BuyingGroup1–5 |
| Contract pricing | dbo.SorContractPrice | CustomerBuyGrp, StockCode, PriceMethod, FixedPrice, FixedUom, StartDate, ExpiryDate |
| Contract pricing with QDB | dbo.SorContractPrice, dbo.SorConQtyDiscBrk, dbo.InvPrice | PriceMethod, ContractType, CustomerBuyGrp, StockCode, Contract, StartDate, ExpiryDate, QtyBreak, QtyPrice, SellingPrice |
| Promotions / special pricing | dbo.SorPriceGroupRules, dbo.SorPriceListDetail | StartDate, ClosingDate, PriceGroup, PriceList, StockCode |
| Customer-specific product rules | dbo.SorPriceListDetail | PriceList, StockCode |
| Rebate-related buying groups | dbo.ArCustomer | BuyingGroup1–5 |
| Order submission | Not confirmed | Not confirmed |
| Customer account status | Not confirmed | Not confirmed |
| Web access permissions | Not confirmed | Not confirmed |
| Stock and availability | Partial | InvMaster.StockCode |
| Order history | Not confirmed | Not confirmed |
| Invoice/document access | Not confirmed | Not confirmed |

## Billing {#billing}

This section covers the commercial and transactional rules that support the customer ordering journey.

It should be read alongside the Pricing Flow and Syspro ERP Flow sections, which define how pricing and customer context are resolved by the backend. Billing-related behaviour includes promotions, currency, stock and availability messaging, basket behaviour, checkout validation, order submission and the relationship between the website and Syspro.

The website should not calculate commercial values independently in the frontend. Pricing, promotional pricing, account eligibility, stock messaging, payment eligibility and order submission should be validated by backend services using the agreed Syspro, EPIM and cached data sources.

This section does not make the website the source of truth for invoices, account balances or formal finance records. Account documents, invoices and permissions are covered separately under Account Dashboard & Self-Service, Documents, Downloads & Resources, and Account Access & Customer Permissions. 

### Promotions & Special Pricing {#promotions-&-special-pricing}

Promotions and special pricing should be handled through the backend pricing logic using Syspro-derived pricing data, rather than being hard-coded into the frontend or CMS.

Promotional pricing is expected to operate within the same overall pricing model as standard pricing, using effective dates, customer/product context and priority rules where applicable.

Promotional pricing should not be hard-coded into CMS content where it affects live product pricing, customer-specific pricing, order totals or checkout values.

Promotions may be surfaced through campaigns or offer landing pages, product listings, product detail pages, basket and checkout, as well as the account dashboard which will surface customer specific promotions. However, any live promotional price displayed to a customer must be resolved by the backend using the agreed pricing.

| Area | Expected handling |
| :---- | :---- |
| Source of truth | Syspro-derived pricing data |
| Display | Frontend displays calculated promotional/special price where returned by backend |
| Date handling | Backend pricing logic should respect effective start/end dates |
| Customer context | Promotions should respect customer, buying group, price group and product context where applicable |
| Conflict handling | Multiple overlapping promotions are not expected for the same customer/product context, but backend logic should still fail safely if unexpected overlaps occur |
| CMS campaigns | CMS can promote offers/campaigns, but must not override calculated prices |

### Currency {#currency}

Syspro is understood to support multiple currencies, with different price lists potentially existing per currency.

The website should support the agreed currency requirements for phase one. GBP is expected to be the primary currency, while EUR support and the extent of multi-currency behaviour should be confirmed before implementation.

Currency handling should be driven by customer/account context and backend pricing logic, rather than by a simple frontend currency switch.

### Stock & Availability {#stock-&-availability}

Stock and availability data is expected to originate from Syspro.

Current discovery indicates that stock is currently updated daily, while more frequent updates may be beneficial to reduce overselling and improve availability messaging. Backorders remain part of the existing business process and should not be removed without business agreement.

The website should present availability in a way that reflects the agreed freshness of the underlying stock data.

Customers should be shown availability messaging (more that 10 / less that 10 units), stocked/non-stocked messaging, back-order messaging, ship-line date logic and make-to-order flag messaging.

### Basket & Ordering {#basket-&-ordering}

The basket should allow eligible users to collect products for purchase, review quantities, see backend-calculated pricing and proceed to checkout.

The website should support pasted/typed part numbers list input directly in the basket, as well as quick add-to-basket from saved lists support. The basket needs to surface alternatives when out of stock, and clear back-order and stock availability messaging before checkout

Basket behaviour must respect product visibility, account permissions, pricing rules and stock/availability messaging.

The basket should not calculate prices independently. It should request pricing updates from the Laravel backend using the relevant customer, product, quantity, date and currency context.

### Checkout {#checkout-1}

Checkout should allow authorised users to complete orders by confirming delivery, billing and order details.

Checkout must remain backend-controlled for validation. The frontend should present the checkout journey, but the Laravel backend should validate account permissions, basket contents, pricing, stock/availability and order submission requirements.

The checkout process should facilitate delivery address capture, address validation, carriage validation and exclusions based on delivery rules, as well as showing cut-off time and collection messaging where appropriate.

### Orders & Order Processing {#orders-&-order-processing}

Orders are expected to be submitted from the website into Syspro through the agreed backend order flow.

Discovery indicates that the current model uses file-based order submission, with orders sent at short intervals. The website is also not the only source of orders; orders may also be entered manually or originate from other systems. This means account/order views should not assume the website is the only order origin.

The website should allow eligible users to see placed orders in the members dashboard, including delivery tracking information when available.

## Payments {#payments}

The payment approach should reflect Europa’s B2B account-based ordering model.

Approved customer users should be able to submit orders through checkout using their existing customer account, where their account status and purchasing permissions allow. Payment behaviour should be determined by backend account data, customer status, payment terms and agreed finance rules.

The website should not assume that immediate online card payment is required for all orders. Card payment should not be treated as a phase one requirement unless confirmed by Europa’s finance team.

Payment handling must be validated by the backend before order submission. The frontend may present the relevant payment or account status messaging, but it must not determine payment eligibility independently.

| Area | Expected handling |
| :---- | :---- |
| Credit account customers | Approved customers with valid account terms can submit orders without immediate online payment |
| Account validation | Backend validates customer account status, purchasing access and payment terms before order submission |
| Pro-forma accounts | Customers requiring upfront payment should receive clear messaging and follow the agreed pro-forma process |
| On-stop accounts | Accounts on stop should be prevented from completing checkout or shown clear next-step messaging |
| Card payments | Online card payment is not assumed for phase one unless confirmed by finance |
| Offline payment | Existing offline payment processes, including bank transfer where applicable, should remain supported operationally |
| Order submission | Orders should only be submitted once account, basket, pricing, delivery and payment rules have been validated |
| Future payment gateway | The architecture should not prevent a future card payment or payment gateway integration if required |
| Security | If online payment is introduced, payment details must be handled by an approved payment provider and must not be stored directly by the website |

## Account Access & Customer Permissions {#account-access-&-customer-permissions}

Account access and customer permissions should be enforced by the backend.

The website should support multiple user states, including logged-out users, registered users, pending users, approved customer users, members/CPD users and internal/admin users. 

Access and permission rules will affect which pages, products, prices, documents and actions a user can access.

| Area | Expected handling |
| :---- | :---- |
| Login state | Determines access to protected areas |
| Customer account link | User(s) linked to a Syspro customer account.  |
| Purchasing access | Restricted until approval/permissions allow |
| Pricing visibility | Customer-specific pricing only shown where authorised |
| Product visibility | Restricted/customer-specific products only shown to permitted users |
| Basket/checkout | Add-to-basket and checkout require permission checks |
| Documents | Invoices/account documents only shown to permitted users |
| Members area | CPD/member content restricted to eligible users |
| Admin access | Managed separately from customer access |

The frontend may adapt the interface based on permissions, but the backend must enforce access. Hiding a button in the frontend is not sufficient.

## Account Onboarding & Approval {#account-onboarding-&-approval}

Account onboarding should allow users to register a new online account against an existing Europa account code while preserving commercial controls around trade pricing and ordering. 

Customer accounts must be validated against existing Syspro records before purchasing is enabled, and manual approval remains required to prevent unauthorised access to trade pricing and ordering.

## Account Dashboard & Self-Service {#account-dashboard-&-self-service}

The account dashboard should act as the central self-service area for approved customer users.

It should provide a clear overview of the customer account, recent account activity, key account status information and routes into common self-service actions. The dashboard should reduce the need for customers to contact Europa manually by making high-value account information easier to access.

The dashboard should provide routes into account-related functions such as order history, invoices, saved lists, returns/support messages and account details.

| Area | Expected handling |
| :---- | :---- |
| Account status | Display the current account status for the logged-in customer account, including whether the account is approved, pending, restricted or otherwise unable to purchase. |
| On-stop status | Display clear messaging where an account is on stop, including where this is due to pro-forma status, unpaid invoices or another account condition. |
| Purchasing access | Make clear whether the user can currently place orders, and provide clear next steps where purchasing is blocked or restricted. |
| Recent orders | Provide quick access to recent orders and order detail pages, subject to account permissions and data availability. |
| Invoices | Provide access to invoices and related account documents where the user has permission to view them. |
| Saved lists | Provide access to saved lists, favourites or commonly ordered products to support repeat ordering. |
| Returns | Provide a route into return-related self-service where return eligibility data is available. |
| Support messages | Provide access to relevant support routes, support messages or enquiry status where available. |
| Account information | Allow users to view and, where appropriate, edit user-level account information. Any changes to source-of-truth account data must be validated by the backend or routed through the agreed internal process. |
| User permissions | Provide access to account user management where the logged-in user has permission to view or manage other users linked to the customer account. |
| Customer-specific promotions | Display active customer-specific promotions where available and relevant to the logged-in customer account. |
| Feedback | Provide a clear route for customers to submit feedback. |
| Custom Solutions | Include a route to Custom Solutions, helping customers understand that Europa can support bespoke requirements. |
| Visit request | Provide a route for customers to request a visit from the external team where this is agreed as in scope. |
| Catalogue request | Provide a route for customers to request a product catalogue where this is agreed as in scope. |

Customer-specific dashboard content must be permission-aware. Information such as pricing, promotions, invoices, documents, orders, returns and user-management options should only be shown where the user is authorised to access them.

Where the dashboard displays account status or purchasing restrictions, messaging should be clear, customer-friendly and action-orientated. Final wording for pending, rejected, on-stop, pro-forma and unpaid-invoice states should be supplied or approved by Europa.

The frontend may adapt the dashboard layout based on account type and permissions, but the backend must remain responsible for enforcing access to account data and self-service actions.

## Members Area & CPD {#members-area-&-cpd}

The members area should provide protected access to CPD, training materials, certificates and member-only resources.

This area should be clearly distinguished from the customer account/buying portal, even if the underlying login system is shared.

The members area should provide members with clear routes into available training materials and CPD content. Training materials should be easy to browse, search and filter, particularly where content volume is high.

Where supported, members should be able to view and amend their own member/account details, subject to backend validation and permission controls. Any fields that are owned by another source-of-truth system must not be overwritten by the frontend without an agreed update workflow.

The exact CPD scope, course structure, certificate handling and content format remain subject to confirmation with Europa. Where course-style functionality is not confirmed, the members area should still support access to searchable and filterable training materials.

## Documents, Downloads & Resources {#documents,-downloads-&-resources}

The website will contain multiple types of documents and downloadable resources. Ownership and access rules should be clear by document type.

EPIM is expected to own product assets such as datasheets and images, while CMS may own editorial resources such as guides, white papers, articles and general downloads. Account-specific documents such as invoices require separate confirmation.

## Forms, Enquiries & Support {#forms,-enquiries-&-support}

Forms should be reusable, accessible, secure and consistent across the site.

Supported form types include:

| Form Type |  |
| :---- | :---- |
| Contact form | General enquiries |
| Support form | Customer support requests |
| Returns form | Returns-related requests |
| Registration form | Account access requests |
| Download form | Gated content/lead capture |
| Newsletter form | Marketing sign-up where required |
| CPD/member enquiry | Member support requests |

Forms should support client-side and server-side validation, spam protection, consent wording, clear error messages and clear success states.

Form submissions should be routed to the agreed internal process, CRM, support platform, email workflow or backend storage depending on form type.

## Live Chat / Support Integration {#live-chat-/-support-integration}

The existing underlying Live chat/support integration feature will remain but the visual implementation will be redeveloped and should provide users with help without disrupting product browsing, account or checkout journeys.

The support integration should support:

| Area |  |
| :---- | :---- |
| Live chat access | Display chat where agreed |
| Fallback routes | Provide contact options when chat is unavailable |
| Contextual support | Link support from product, basket, checkout and account areas |
| Mobile support | Ensure chat/contact routes work on mobile |
| Ticket creation | Support ticket/enquiry submission where agreed |
| Analytics | Track support interactions where permitted |
| Consent/privacy | Respect cookie and tracking preferences |

## Data Switch & Integration Flows {#data-switch-&-integration-flows}

### Cached Data Layer {#cached-data-layer}

The cached data layer is expected to store synchronised data required for the website to operate efficiently.

It includes:

* Product data retrieved from the EPIM API  
* Product attributes and categories  
* Product status information  
* Search/indexing data  
* Pricing-supporting data retrieved from Syspro SQL  
* Customer/account data required for access and pricing  
* Stock or availability data retrieved from Syspro SQL  
* Restricted product rules  
* Other synchronised integration data required by the backend

The cached data layer should improve:

* Performance  
* Resilience  
* Search/filter speed  
* Product listing speed  
* Pricing lookups

## Synchronisation Strategy {#synchronisation-strategy}

The integration model should be domain-specific. Different types of data require different synchronisation patterns

| Data Domain | Expected Source | Approach |
| :---- | :---- | :---- |
| CMS content | Headless WordPress | Published via CMS and consumed by frontend/backend |
| Product data | Existing EPIM | Scheduled or delta-based synchronisation into cached data layer |
| Product assets | Existing EPIM | Referenced or synchronised depending on asset delivery model |
| Pricing data | Existing Syspro ERP | Synchronised into backend/cached layer for pricing engine use |
| Customer/account data | Existing Syspro ERP | Regular synchronisation or agreed account lookup process |
| Stock/availability | Existing Syspro ERP | More frequent sync desirable; final frequency to be confirmed |
| Orders | Website to Laravel to Existing Syspro ERP | Submitted through agreed backend order flow |
| Analytics | Website to GA4 | Event/page tracking subject to consent |
| Support/live chat | Support provider / Live Agent | Integration approach to be confirmed |

## Data Quality & Validation {#data-quality-&-validation}

Data quality is a key dependency for the website because core website behaviour will rely on data from EPIM, Syspro, Data Switch, the CMS and any connected third-party systems.

The website should apply validation where data is ingested, transformed, cached, displayed or submitted back into connected systems. This should reduce the risk of incomplete, inconsistent or incorrect data affecting product discovery, pricing, account access, checkout or customer self-service.

| Area | Expected handling |
| :---- | :---- |
| EPIM product data | Validate required product fields, category assignment, attributes, assets and publication status before products are exposed |
| Syspro pricing data | Validate pricing-support data before it is used by backend pricing logic |
| Customer/account data | Validate account identifiers, account status, customer mappings and permission-related fields where available |
| Stock/availability data | Validate that stock indicators can be safely displayed and do not imply unsupported real-time accuracy |
| Forms | Validate required fields, input formats, consent fields and spam/bot protection |
| Basket and checkout | Revalidate product eligibility, pricing, stock/availability and account permissions before order submission |
| CMS content | Ensure CMS-managed content does not override system-controlled product, pricing or account data |
| Imports/syncs | Log failed imports, missing fields, invalid records and unexpected data formats |
| Anomalies | Exceptional products, restricted products and unusual pricing scenarios should be tested using supplied sample data |

## Security & Access Control {#security-&-access-control}

Security should be applied across public pages, protected account areas, members/CPD content, CMS administration, integrations, forms, basket and checkout.

The frontend may adapt what a user sees, but the backend must enforce access and permission rules. Hiding buttons or links in the frontend is not sufficient where pricing, ordering, account data, documents or restricted products are involved.

| Area | Expected handling |
| :---- | :---- |
| Authentication | Secure login, logout, password reset and session handling |
| Account protection | Protected access to customer account areas and account-specific data |
| Members area | Protected access to CPD/member-only content |
| Product visibility | Restricted/customer-specific products must not be exposed to unauthorised users |
| Pricing visibility | Customer-specific pricing should only be returned for authorised users/accounts |
| Checkout access | Checkout should only be available to approved purchasing users |
| Document access | Invoices, account documents and certificates should only be visible to permitted users |
| Forms | Forms should include validation, consent handling and spam/bot protection |
| Integrations | Data transfer between systems should use secure agreed methods |
| Auditability | Key account/admin/security actions should be auditable where appropriate |
| Data protection | Personal and account-related data should be handled securely and in line with privacy requirements |

Security expectations should include SSL/TLS, secure authentication, secure admin access, role-based permissions, appropriate logging and safe error handling. Error messages should not expose sensitive information, system details or approval logic.

## Admin Access & Permissions {#admin-access-&-permissions}

Website admin access should be managed separately from customer account access.

Admin permissions should control who can manage CMS content, page builder pages, media, forms, SEO metadata, redirects, users, settings and any operational admin functions.

| Admin area | Expected handling |
| :---- | :---- |
| CMS access | Only approved internal users should access the CMS/admin area |
| MFA / 2FA | 2FA should be required for admin users where supported |
| Role-based admin permissions | Admin users should only access the tools needed for their role |
| Content editing | Editors should manage approved CMS/page builder content |
| Publishing | Publishing rights may be restricted to senior editors/admins |
| Media management | Admin users may manage CMS-owned images, documents and downloads |
| SEO/admin settings | Access to global SEO, redirects or settings should be limited |
| User/admin management | Only authorised admin users should manage other admin users |
| Audit logging | Key admin actions should be logged where appropriate |
| Separation from Syspro | Website admin accounts should not be assumed to be Syspro accounts |

Admin access should not allow users to manually override EPIM product data, Syspro pricing, restricted product rules, stock data or customer/account permissions unless a specific controlled workflow is agreed.

## Analytics & Tracking {#analytics-&-tracking}

Analytics should provide visibility of how users interact with the website, including product discovery, account journeys, forms, content engagement, basket and checkout.

GA4 is expected to be used for website analytics, subject to final access and tracking configuration. Tracking should respect cookie consent and privacy preferences.

## SEO {#seo-1}

SEO will be supported through a combination of structured content, metadata management and frontend rendering strategy.

Key public-facing pages, including product, category, CMS and landing pages, should be delivered as pre-rendered or cached HTML to ensure they are accessible to search engine crawlers without reliance on client-side rendering.

Metadata such as page titles, meta descriptions, canonical URLs and social sharing data will be managed within the CMS and exposed in a structured format for frontend use.

Sitemap and robots.txt generation should be handled as part of the build or deployment process, using available content and product data.

Redirects for legacy or migrated URLs shall be supported as part of the content migration and SEO process.

A redirect strategy shall be produced before launch, identifying which legacy URLs need to be redirected to new product, category, resource, article or CMS-managed pages.

Where content is migrated or replaced, permanent 301 redirects should be implemented to the most relevant equivalent destination.

Redirects may be managed at CMS, application, hosting or edge/CDN level depending on the URL type, volume and technical implementation. The final redirect layer shall be agreed during implementation.

Access to create or manage redirects should be limited to authorised admin users with appropriate SEO or technical permissions.

Performance optimisation, including caching and asset optimisation, should support Core Web Vitals and overall search performance.

## Accessibility {#accessibility-1}

Accessibility should be supported through consistent use of semantic HTML, accessible components and structured content, aligned with WCAG 2.2 AA standards.

All key templates and page builder components should be designed and implemented to meet accessibility requirements, including appropriate heading structure, keyboard navigation and screen reader compatibility.

Interactive elements such as navigation, forms and dynamic components should be operable via keyboard and provide clear focus states.

Forms should include properly associated labels, clear validation messaging and accessible error handling.

Media content should support alternative text, captions or transcripts where appropriate.

Colour contrast, typography and layout should ensure readability across devices and user needs.

Accessibility should be maintained across CMS-managed content, with guidance or constraints in place to prevent inaccessible content being created.

## Performance {#performance-1}

Performance should be supported through efficient frontend rendering, optimised asset delivery and appropriate caching strategies.

Key public-facing pages should be delivered as pre-rendered or cached content where appropriate to reduce load times and improve initial render performance.

Frontend assets such as JavaScript, CSS and images should be optimised, minimised and delivered via CDN.

API interactions should be efficient and limited to dynamic data requirements, avoiding unnecessary requests and ensuring fast response times.

Caching should be applied across content and data layers where appropriate, with clear strategies for cache invalidation when content or data is updated.

Non-critical content and functionality should be loaded progressively or deferred to improve initial page load performance.

Performance should be monitored against Core Web Vitals and maintained across key user journeys.

## Environments, Testing & Deployment {#environments,-testing-&-deployment}

The project should include appropriate environments for development, testing, client review and production deployment.

Environments should support safe development, integration testing, client validation and controlled release without exposing unfinished work, test data or non-production systems to public users or search engines.

### Environments {#environments}

The expected environment structure is:

| Environment | Purpose | Expected handling |
| :---- | :---- | :---- |
| Development | Used by the development team for active build work, integration setup and internal testing. | May use test data, sandbox integrations and non-production configuration. Access should be restricted to the project team. |
| Staging / UAT | Used for client review, user acceptance testing, regression testing and pre-launch validation. | Should closely reflect production configuration, integrations and data behaviour where safe and practical. Access should be restricted to authorised Platform and Europa users. |
| Production | The live customer-facing website. | Should only receive approved, tested and release-ready changes through the agreed deployment process. |

Non-production environments should be protected from public access and search engine indexing. Where production-like data is required for testing, data should be sanitised or permission-controlled as appropriate.

Where integrations are required, non-production environments should use sandbox, test or controlled endpoints where available. This includes CMS, EPIM, Syspro/Data Switch, support/live chat, analytics and any delivery or email-related services.

### Testing approach {#testing-approach}

Testing should cover the key website journeys, integrations and non-functional requirements before launch.

Testing should include:

| Test area | Expected coverage |
| :---- | :---- |
| Functional testing | Page templates, navigation, forms, CMS-managed content, page builder components, search, product pages, basket, checkout and account journeys. |
| Integration testing | EPIM product data, Syspro-derived customer/pricing/stock data, Data Switch flows, support routing, analytics and any agreed third-party tools. |
| Data validation testing | Product data, pricing-support data, stock/availability indicators, account data, permissions, imports, sync failures and exceptional product scenarios. |
| Pricing and visibility testing | Customer-specific pricing, restricted products, customer-specific products, product status, partial-hold/full-hold behaviour and account-based access. |
| Account and permissions testing | Login, registration, account approval states, purchasing access, user permissions, order history, invoices, documents, returns and dashboard visibility. |
| Basket and checkout testing | Basket persistence, saved lists, revalidation of products/pricing/stock/account permissions, delivery address handling, carriage rules, cut-off messaging and order submission. |
| Returns and support testing | Return eligibility, return request flow, support form routing, Live Agent/email workflow continuity and support messaging. |
| CMS/editor testing | Content editing, preview, publishing, media management, SEO fields, redirects, reusable components and role-based CMS permissions. |
| Accessibility testing | WCAG 2.2 AA-aligned checks across key templates, forms, navigation, account journeys and interactive components. |
| Responsive and browser testing | Desktop, tablet and mobile layouts across agreed browsers and devices. |
| Performance testing | Core Web Vitals, page speed, asset optimisation, API response behaviour, caching and key user journeys. |
| Security testing | Authentication, session handling, admin access, role-based permissions, form security, safe error handling and protection of restricted data. |
| Regression testing | Re-testing of key journeys after fixes, integrations, content changes or deployment preparation. |

Testing should include supplied sample data and edge cases where available, including restricted products, unusual pricing scenarios, customer-specific products, account states, return eligibility examples and order/invoice examples.

### User acceptance testing {#user-acceptance-testing}

Europa stakeholders should be involved in validating the areas relevant to their ownership.

| Area | Suggested UAT owner |
| :---- | :---- |
| Frontend, UX, CMS and content | Jo |
| Account dashboard, returns, support, order access and customer experience | Chloe |
| Pricing, commercial rules and customer-specific visibility | Steve / Andrew |
| EPIM product data, attributes, assets and product structure | Steve / Marc / Andrew |
| Security, access control and integrations | Elaine |
| Final approval and scope validation | Sonia / agreed Europa approvers |

Chloe should be involved in testing the returns process and user-access permissions, as these areas are closely linked to account management, order processing, delivery and customer support.

UAT feedback should be logged against the relevant page, requirement ID or user journey. Any change that affects agreed scope, integrations, pricing, permissions, checkout, order processing or data ownership should be reviewed before being accepted.

### Deployment approach {#deployment-approach}

Deployment should follow a controlled release process.

Before launch, the project should include:

| Area | Expected handling |
| :---- | :---- |
| Content readiness | Required CMS content, page builder content, product/category content and key support content reviewed and approved. |
| Data readiness | EPIM, Syspro, cached data layer and required sync processes validated with agreed sample data and edge cases. |
| Integration readiness | Required integrations tested in the appropriate environment, including CMS, EPIM, Syspro/Data Switch, support/live chat, analytics and delivery-related services. |
| SEO readiness | Metadata, sitemap, robots.txt, canonical handling and redirect strategy reviewed before launch. |
| Accessibility readiness | Key templates and journeys checked against agreed accessibility expectations. |
| Performance readiness | Core pages and journeys checked for load time, asset optimisation, caching and API performance. |
| Security readiness | Admin access, authentication, permissions, form protection, environment access and safe error handling reviewed. |
| UAT sign-off | Relevant Europa stakeholders have reviewed and accepted their areas of responsibility. |
| Rollback planning | A rollback or recovery plan should be in place before production release. |
| Monitoring | Post-launch monitoring should be in place for errors, integration issues, analytics, performance and critical user journeys. |

Deployment should include appropriate backups, configuration checks, cache invalidation, DNS/CDN updates where required and post-launch smoke testing.

After launch, the project team should monitor key journeys such as homepage, search, product listing, product detail pages, login, account dashboard, basket, checkout, forms and support routes. Any launch issues should be triaged by severity and resolved through the agreed support process.

## Appendix: Project Terminology {#appendix:-project-terminology}

| Term / acronym | Meaning | Example |
| :---- | :---- | :---- |
| Account permissions | Rules that decide what a logged-in user can see or do. | A user linked to a Europa customer account may be able to view invoices, order history and customer-specific pricing, while a logged-out user cannot. |
| Accessibility | Designing and building the website so people with different needs and assistive technologies can use it. | Forms, navigation and account pages should be usable by keyboard and screen readers. |
| API | Application Programming Interface. A structured way for systems to send and receive data. | The frontend may request product data, CMS content or pricing results through backend APIs rather than connecting directly to source systems. |
| Backend | The server-side logic and services behind the website. | The Laravel backend validates account permissions, pricing, basket rules and checkout logic. |
| Basket | The area where users collect products before placing an order. | A logged-in wholesaler adds products to the basket, reviews quantities and then proceeds to checkout. |
| Buying access | Whether a user/account is allowed to purchase. | An approved customer account may be able to checkout, while a pending or on-stop account may be blocked. |
| Buying group | A Syspro customer/pricing grouping used in pricing rules. | A customer may receive different pricing because of the buying group linked to their Syspro account. |
| Cached data layer | A stored copy of data used to improve performance and reduce repeated calls to source systems. | EPIM product data and Syspro pricing-support data may be cached so product pages and search results load quickly. |
| Cache invalidation | The process of clearing or refreshing cached data when the source data changes. | If product data changes in EPIM, the website cache may need to refresh so the latest description or status is shown. |
| Carriage | Delivery or shipping charge. | A customer delivery address in the Scottish Highlands may require different carriage rules from a standard UK mainland address. |
| CDN | Content Delivery Network. A service that helps deliver website assets quickly from locations closer to the user. | Product images, scripts and static assets may be served through a CDN to improve page speed. |
| Checkout | The process where an eligible user confirms delivery, billing and order details before submitting an order. | Checkout validates the customer account, basket contents, stock messaging, delivery address and payment/account status before order submission. |
| CMS | Content Management System. A system used by editors to manage website content. | Europa users may use the CMS to edit homepage content, resources, articles, downloads and page-builder content. [https://wordpress.com/](https://wordpress.com/)  |
| CMS-managed content | Website content owned and edited in the CMS. | A homepage banner or article intro is CMS-managed; product pricing is not. |
| Cookie consent | The mechanism that asks users to accept or manage cookies and tracking preferences. | Analytics tracking should respect whether the user has accepted the relevant cookies. |
| Core Web Vitals | Google performance measurements for page speed, responsiveness and visual stability. | Product category pages and the account area should perform well against Core Web Vitals. |
| CPD | Continuing Professional Development. Training or educational content used to support professional learning. | Europa’s members area may include CPD materials, course content or certificates where scope is confirmed. |
| CRM | Customer Relationship Management system. A tool for managing customer and lead information. | A contact form submission could be routed to a CRM if Europa agrees that integration. |
| CTA | Call to Action. A button or prompt that encourages a user to take a next step. | “Open an account”, “Request a catalogue” or “Add to basket” are CTAs. |
| Customer code | The existing Europa/Syspro account identifier for a customer. | A user may need an existing Europa customer code to register for online account access. |
| Customer-specific pricing | Pricing shown only to authorised users based on their account. | A logged-in customer sees the price they qualify for, calculated from Syspro-derived pricing data. |
| Customer-specific product | A product only visible or purchasable by a specific customer/account. | A branded product made for one customer should not be shown to other customers. |
| Data Switch | Middleware that helps transform and move data between systems. | Syspro data may be processed through Data Switch before being made available to the website. [https://www.syspro.com/product/dataswitch/](https://www.syspro.com/product/dataswitch/)  |
| Data validation | Checks that data is complete, safe and usable before it is displayed or submitted. | The website should validate product, pricing, stock and account data before using it in checkout. |
| Decoupled frontend | A website frontend that is separate from the CMS and backend systems. | Europa’s frontend can render content from the CMS, EPIM and backend services without being tightly tied to WordPress or Syspro. |
| Delta sync / delta endpoint | A synchronisation method that sends only changed data rather than everything. | EPIM may provide updated product records only, rather than sending the full product catalogue each time. |
| Development environment | A non-live environment used by the project team during build. | Developers use this to build and test features before they are reviewed by Europa. |
| DPD tracking | Parcel tracking information from DPD. | The account area may show DPD tracking references where available for an order. [DPD Developer Documentation](https://www.dpd.com/wp-content/uploads/sites/235/2023/04/DPD-API-documentation-v1-2-1.pdf)  |
| EDATA | A structured product data standard used in the electrical industry. | Product filters such as amperage, voltage or dimensions may be based on EDATA/ETIM-style fields. |
| EPIM | Europa’s Product Information Management system. It is the source of truth for product data. | Product descriptions, attributes, categories, images and datasheets should come from EPIM. [https://epim.online/](https://epim.online/)  |
| ERP | Enterprise Resource Planning system. A business system used for operational data such as customers, pricing, stock and orders. | Syspro is Europa’s ERP. |
| ETIM | A standardised classification model for technical product data. | ETIM attributes can help create accurate product filters for electrical components. [https://www.etim-international.com/](https://www.etim-international.com/)  |
| Fallback behaviour | What the website does when expected data or an integration is unavailable. | If a live stock feed is delayed, the website should show safe availability messaging rather than incorrect stock. |
| Frontend | The customer-facing part of the website that users see and interact with. | Product pages, account dashboard screens, basket and checkout are frontend experiences. |
| Full hold | A product status meaning the product has sold out and will not be sold again. | A full-hold product should not be purchasable and should show unavailable or discontinued messaging if visible. |
| GA4 | Google Analytics 4\. Google’s analytics platform. | Europa can use GA4 to track page views, search, forms, product views, basket and checkout journeys where consent allows. [https://analytics.google.com/](https://analytics.google.com/)  |
| Gated content | Downloadable or protected content that requires the user to provide details or log in first. | A white paper or technical resource may ask for name, email and company before download. |
| Headless CMS | A CMS that stores and manages content but sends it to a separate frontend via API. | Europa editors manage content in the CMS, while the Vue frontend renders it for users. |
| Indexing | Making content available to search engines or site search. | Product data from EPIM and article content from the CMS can be indexed so users can find them. |
| Integration | A connection between two systems or services. | The website integrates with EPIM for product data and Syspro/backend services for pricing and customer account information. |
| Laravel | The backend framework proposed for server-side application logic. | Laravel services handle account, basket, checkout, pricing, search and integration logic. [https://laravel.com/](https://laravel.com/)  |
| Live Agent | Europa’s support/ticketing system. | A support form may collect better data on the website while still routing into Live Agent or an agreed email workflow. [https://www.liveagent.com/](https://www.liveagent.com/)  |
| Metadata | Behind-the-scenes page information used by browsers, search engines and social platforms. | Page title and meta description help search engines understand a product category or article. |
| MFA / 2FA | Multi-factor authentication / two-factor authentication. An extra security step after entering a password. | Admin users may be required to use 2FA when accessing the CMS or admin area. |
| MoSCoW | A prioritisation method: Must, Should, Could, Won’t. | A “Must” requirement is required for the project, while a “Could” is lower priority. |
| NPS | Net Promoter Score. A customer satisfaction measure based on how likely users are to recommend a business. | Europa may capture NPS from logged-in users through a survey or questionnaire. |
| On-stop account | An account state where purchasing is blocked, often for finance or account reasons. | If a customer is on stop due to unpaid invoices, the dashboard and checkout should show clear messaging. |
| Page builder | A CMS editing tool that lets editors build pages using predefined components. | Europa editors could create a landing page using approved blocks such as hero, text, media, CTA and banner sections. |
| Partial hold | A product status meaning the product is being discontinued but remaining stock may still be available. | A partial-hold product may remain visible and purchasable while stock exists, with limited availability messaging. |
| PDP | Product Detail Page. The individual page for a single product. | A fuse product page showing images, product code, description, specifications, price, stock messaging and add-to-basket controls. |
| Pre-rendering | Creating page HTML before the user or search engine requests it, instead of relying entirely on client-side rendering. | Key product/category/CMS pages may be pre-rendered so search engines can read them more easily. |
| Product attributes | Structured product details used for specifications, filtering and search. | Voltage, amperage, dimensions, material or rating may be product attributes from EPIM. |
| Product visibility | Rules that decide whether a product can be shown to a user. | Restricted or customer-specific products should only be visible to authorised customers. |
| Production environment | The live customer-facing website. | Changes should only reach production after testing and approval. |
| Pro-forma account | An account type where payment may be required before goods are supplied. | A pro-forma customer may not be able to submit an order on account in the same way as a credit account customer. |
| QDB | Quantity Discount Breaks. Pricing that changes at specific quantity thresholds. | Buying 10 units may trigger a better price than buying one, depending on the Syspro pricing rules. |
| Regression testing | Re-testing key journeys after changes to make sure nothing has broken. | After a checkout bug is fixed, the team re-tests basket, pricing, delivery and order submission. |
| Restricted product | A product that should not be exposed to all users. | A product contractually restricted to certain customers should not appear in unauthorised users’ search or product listings. |
| Robots.txt | A file that tells search engines which parts of the site they should or should not crawl. | Non-production or restricted areas should not be indexed by search engines. |
| Rollback | A plan for reverting a release if something goes wrong. | If launch introduces a critical checkout problem, the team may need to roll back to the previous stable version. |
| SEO | Search Engine Optimisation. Making pages easier for search engines to find, understand and rank. | Product category pages should include SEO-friendly headings, metadata and useful content. |
| Server-rendered HTML | HTML generated by the server rather than only in the user’s browser. | Important product and category pages may be served as HTML to support SEO and performance. |
| Session handling | Managing a user’s logged-in state securely. | The website must keep users logged in safely and log them out appropriately. |
| Ship line | Syspro/order line delivery information used to indicate expected fulfilment dates. | Back-order messaging may depend on ship-line dates calculated from stock, purchase orders and lead times. |
| SKU | Stock Keeping Unit. A unique product code. | Each Europa product in EPIM/Syspro has a SKU used for lookups, pricing, search and ordering. |
| Smoke testing | A quick post-deployment check of critical journeys. | After deployment, the team checks homepage, search, login, product pages, basket, checkout and forms. |
| Source of truth | The system that owns the master version of a type of data. | EPIM is the source of truth for product data; Syspro is the source of truth for pricing and account data. |
| SQL | Structured Query Language. A language used to query databases. | Syspro SQL access may be used to read pricing-support, customer/account or stock-related data. |
| SSL / TLS | Security protocols that encrypt data between the user and website. | Login, account and checkout pages must use secure HTTPS connections. |
| Staging / UAT environment | A non-live environment used for client review and user acceptance testing. | Europa stakeholders review key journeys on staging before launch. |
| Syspro | Europa’s ERP system and source of truth for pricing, customer, stock and order-related data. | The website uses backend services and cached data to consume Syspro-derived pricing and account information. [https://www.syspro.com/](https://www.syspro.com/)  |
| Taxonomy | The structured organisation of content or products into categories and groups. | EPIM category data helps organise products into product categories and subcategories. |
| Ticket | A support record created for tracking a customer enquiry. | A support form may create or support a Live Agent ticket for customer service teams. |
| UAT | User Acceptance Testing. Testing by client stakeholders to confirm the system works as expected. | Chloe validates account dashboard, returns and access-permission journeys before sign-off. |
| UI | User Interface. The screens, controls and visual elements users interact with. | Buttons, forms, filters, navigation and product cards are UI elements. |
| URL redirect | Sending users and search engines from an old URL to a new URL. | If an old product guide URL changes during migration, a redirect should send users to the new equivalent page. |
| UX | User Experience. How easy, useful and smooth the website feels for users. | Improving product search and account self-service improves UX for wholesalers and customers. |
| Vue | The frontend JavaScript framework used to render the website interface. | CMS page-builder components can map to Vue components on the frontend. [https://vuejs.org/](https://vuejs.org/)  |
| WCAG 2.2 AA | Web Content Accessibility Guidelines, version 2.2, AA level. | The website should align with WCAG 2.2 AA expectations across key templates and journeys. |
| XML sitemap | A file listing important website URLs for search engines. | Product, category, article and resource pages may be included in the XML sitemap. |
| 301 redirect | A permanent redirect from one URL to another. | If a legacy resource page is replaced, a 301 redirect should point users and search engines to the new page. |