eCommerce Website

At the moment, the delivery address form shows the postcode lookup below Line 1, Line 2 and City. This leads to a common behaviour pattern: Customer fills in Line 1, Line 2 and City manually. They then enter their postcode and hit the search icon. The lookup either overwrites what they have typed or does nothing if clicked. This slows the checkout down and feels clunky compared with other UK ecommerce checkouts, where the postcode is the first step. Proposal -------------------- Move the Postcode field and lookup button to sit directly under the phone number field, above the address lines. When the customer reaches the Delivery Address section, set the cursor focus to the postcode field by default. After the postcode is entered and the lookup is used, auto populate Line 1, Line 2, City and Country as it does now. Why this helps -------------------- Matches how UK customers expect address lookup to work - postcode first, then select address. Reduces typing and re work Speeds up checkout completion and reduces friction on a key step in the funnel. Improves overal flow Visual example -------------------- Screenshot 1 - current layout with postcode below address lines. Screenshot 2 - suggested layout with postcode and lookup at the top of the address block.

When an egift voucher is sold through the website, the customer still gets delivery information like they're getting something physical through the post. this causes an increase in customer contacts. We need a delivery option that does not say this or says something like "digital delivery within 24 hours". that will stop customer contacts and will ease customer's minds

Add a Trustpilot integration to Citrus-Lime that matches (or exceeds) the current Shopper Approved feature set: automated review invitations, company widgets, and product-level ratings rendered on product pages and product listing (Find & Filter) pages - without manual per-product work. Problem -------------------------------------- Shopper Approved is currently the only native option. Trustpilot has materially stronger brand recognition, better search visibility, and is the first result many users see when they search for “[brand] reviews”. The current Trustpilot approach (Google Tag Manager [GTM] widgets plus manual code) cannot: -- Show stars next to the product title on product detail pages (PDPs). -- Show rating badges on product tiles in product listing pages / Find & Filter pages (PLPs/FAF). -- Scale automatically (manual insertion per product is not viable). Without automation, we lose the search engine optimisation (SEO), user experience (UX), and conversion benefits that Trustpilot provides. What we’re asking for (scope) -------------------------------------- Automated review invitations Support Trustpilot’s “blind carbon copy” (BCC) to invite pattern by allowing a fixed BCC address on order confirmation emails or a supported server-side call to Trustpilot’s Application Programming Interface (API) for Invitations. Include order ID, customer email, name, item list, and send-delay where supported. Company review widgets Site-wide TrustBox placement options (header bar, footer badge, homepage block, dedicated reviews page). Configurable via Merchant Tools (MT) - enable/disable, widget type, and placement. Product-level rating display PDP: show Trustpilot product rating adjacent to the product title, with a link/anchor to the reviews section or a TrustBox Product Reviews widget. PLP/FAF: show rating stars and count on product tiles. Phase 2 (nice to have) -------------------------------------- Caching/synchronisation layer for performance Nightly (or frequent) import of product rating and count via Trustpilot API into a lightweight Citrus-Lime data store; render from cache to avoid live per-product API calls. Include time-to-live (TTL) and manual re-sync controls in MT. Structured data Emit product aggregateRating schema (structured data for search engines) on PDPs using the cached Trustpilot rating/count to support rich results, where policy permits. Admin configuration in MT Global toggle, widget choices, API credentials, BCC email field (if supported), invite delay, and per-template switches (PDP/PLP). Technical notes (suggested approach) -------------------------------------- Invites: Prefer a server-side call to Trustpilot’s Invitations API after order creation. If platform constraints prevent that, expose a fixed BCC field on order confirmations so Trustpilot can ingest orders automatically. Ratings data: -- Avoid client-side API calls per product. -- Implement a scheduled job to fetch a simple mapping {sku → rating, count, last_updated} and store it in Citrus-Lime; render stars server-side (or via a single batched payload per page). Widgets: Load TrustBox asynchronously and defer where possible; provide a minimal “no-JavaScript fallback” for critical badges. Ideally, we'd have -------------------------------------- New orders automatically trigger the Trustpilot invite flow (via API or BCC). PDPs show Trustpilot star rating and count next to the title for products with reviews. PLP/FAF tiles display stars and counts without noticeable performance impact. No manual per-product template edits required. MT provides a simple configuration panel. Ratings render even if Trustpilot JavaScript is blocked (using cached values). Structured data (aggregateRating) present on PDPs when data is available. Constraints -------------------------------------- Do not expose Trustpilot API keys on the client side. Live per-product API calls at page render are out of scope for performance reasons. Shopper Approved remains available; this request adds Trustpilot as a peer integration. Benefits -------------------------------------- Trust and conversion: Recognised review brand with visible stars in all decision points (PLP + PDP + site-wide). SEO: Eligibility for rich results (where permitted) and alignment with the review brand customers actually search for. Operational efficiency: Automated invitations; no manual per-product embedding. Platform value: A reusable, configurable integration that other Citrus-Lime retailers can adopt.

Maybe there's some logic I'm unaware of but we're allowed special characters on other pages but on the Product Page Sorry, validation failed for your request Field: Name Plural You can only set alpha numeric characters 'A-Z', 'a-z', '0-9', spaces, and these characters . : + - / ! % ' in the field 'NamePlural'. You can get round it by saving it without and saving again with, but it's a time drain.

Our customer service bot is receiving a lot of messages about customers wanting to change their email address. I’ve tried updating my own as a test, but the field is greyed out and cannot be edited. Is it possible to make this field editable?

It would be really helpful if customers could cancel their own pending or unshipped orders directly from their account page without needing to contact customer service. We get contacted about this multiple times a day, and self-service cancellation would: Reduce customer service workload Improve customer experience and speed Prevent frustration outside business hours

I was trying to find existing posts related to this to find out where we are up to. At the moment the only sash options that I know of that we can use are "sale" "coming soon" "pre Order" or "core range" Is there are plan to allow these sash messages to be more useful. I would like the option to add things such as "limited stock" "last few" "2026 bike" etc etc.

It is becoming increasingly difficult to accommodate product launches when a scheduling feature isn't available. Brands are launching full collections of sometimes 20-30 products at 6am or even midnight and having to manually tick up these products isn't feasible. Our previous platform Shopify had a bulk schedule tool which worked perfectly and took the stress out of keeping up and adhering to company launch T&Cs. I am sure other retailers on this platform feel the same way! We just need a suitable solution :)

The layout does not adapt properly when viewed on mobile devices, causing elements to appear broken, misaligned, or overflow the screen.

We have various companies working with us to improve the customer experience. sometimes when they link to category pages either the system they are using or they manually add a / to the end of the URL which causes a page not found e.g. https://www.balfesbikes.co.uk/pedals-and-cleats vs https://www.balfesbikes.co.uk/pedals-and-cleats/ obviously, we correct these and tell them the proper formatting, but would be useful if the system might be able to automatically redirect to the non '/' not sure if there's other SEO benefits or issues with this?