FiftyFlowers · Storefront and operations

Storefront requests, delivered ready to act on.

Two storefront flows: rush-order requests that reach support as ready-to-answer tickets, and contest entries turned into review cards and draft store bundles.

PROJECTStorefront requests

MY ROLEAI Solutions Engineer · FiftyFlowers

STAGERush form live · contest processing run on 2025 entries

Two views of the rush-order form: a product search listing matches, and two chosen products with size and quantity

The rush-order form: searching the catalog, then two products chosen with size and quantity. A local run of the theme’s own form with invented products; nothing was typed into the live form.

The context

A problem worth solving.

Some storefront requests need a person to act: flowers needed sooner than standard delivery, or a couple sharing their event for the yearly contest. Each has to reach the right team complete, with nothing to re-type.

My contribution

What I brought to the work.

Built the rush-order form and its request function, from a one-day prototype to the live version. Built the processing step behind the existing Share Your Flair form, ran it over every 2025 entry, then repaired and audited the media.

The product

What it makes possible.

Three parts follow: the rush form in use, what customer service receives, and what the contest step writes for one entry.

A rush request in one step

Customers choose event and delivery dates, pick exact products from the live catalog with size and quantity, and add contact details and addresses. The form checks it all before sending.

A ticket in the customer’s voice

Each request becomes one formatted email to the customer-service inbox with the customer as reply-to, so it opens as a helpdesk ticket the team can answer directly.

An acknowledgment right away

The customer immediately sees a thank-you that explains the next step and asks them to stay reachable while farms are contacted.

One entry, two team workflows

The Share Your Flair step turns a saved contest entry into two review cards for marketing and a draft store bundle built from the couple’s photos, story and ordered products.

Every 2025 entry, read back

Every 2025 entry went through it. After a May 2026 repair, a read-only audit found none of the 640 media links broken and every draft photo in place.

At a glance / simplified product view

01Storefront form
02Checks and routing
03Ticket or review cards

Rush orders · the storefront form

A request the form has already checked.

Live on the storefront since October 2025

A customer who needs flowers sooner than standard delivery fills in one form: dates, exact products from the catalog with size and quantity, contact details and addresses. The form checks each part as it goes and refuses what cannot work, such as a Sunday delivery. These pictures are the store theme’s own form running on my machine with invented products and an invented customer. Nothing was typed into the live form.

Two views of the rush-order form: a product search listing four matches, and two chosen products with size and quantity — **Exact products, not a description**Typing in the product box lists matches from the catalog. Picking one adds a row with a link to the product, a size menu with each size’s price, and a quantity. The products, prices and pictures are invented. Local run, invented data.

Two views of the form’s date boxes with red messages under refused dates — **Dates that cannot work are refused**An event date of today, a Sunday delivery and a delivery after the event are each refused with a message under the date. Local run, invented data.

The contact section of the form with four boxes outlined in red and a message under each — **Checked while typing**A digit in the name, an unfinished email address, a phone number cut short and a wrong character in the postal code each get a message as they are typed. Local run, invented data.

The rush-order page showing a green thank-you notice in place of the form — **An acknowledgment right away**After sending, the form is replaced by a notice that says when the team will be in touch and asks the customer to stay reachable. Local run, invented data.

The rush-order page with a red notice above the filled form — **When sending fails**If the request cannot be sent, a notice says so and the form stays filled, ready to send again. Local run, invented data.

Three phone-width views of the rush-order form — **On a phone**At phone width every section sits in one column and each chosen product stacks its name, link, size and quantity. Local run, invented data.

Rush orders · the request function

One email the team can answer directly.

The request function checks everything again, then writes one email in the customer’s voice with the customer as reply-to, so it opens as a helpdesk ticket the team can answer without re-typing anything. These are the function’s own outputs for the request typed into the local form. The mail service was replaced by a recorder, and nothing was sent.

A formatted rush order request email with order details, customer information, billing and shipping addresses — **The email customer service receives**Written in the customer’s voice with the customer as reply-to, so it opens as a ticket the team can answer directly: the order line by line, the customer, both addresses and a rush banner. The addresses in the header are stand-ins, and the email was recorded, not sent. Local run, invented data.

A request with four missing fields and the function’s reply listing four errors — **Checked again on the server**The function does not trust the browser: it checks every request again and answers a bad one with a list of what is wrong. Local run, invented data.

A text-only rush order request email with event details and two addresses — **Where it started: the one-day prototype**The first version’s email, September 2025: the same idea, a web form turned into an email the team can act on, before formatting, product links or the customer’s voice. Rebuilt by running the retired prototype’s own code with an invented request. Local run, invented data.

Share Your Flair · the processing step

One contest entry becomes two pieces of team work.

Run on every 2025 entry · fixes for new entries awaiting release

When a couple shares their event, the processing step turns the saved entry into a contest review card, a Make This Look card, a draft store bundle built from their photos, story and ordered products, a page that downloads all their media in one click, and a thank-you email. These pictures show what the step writes, from one run of its own code on my machine with an invented entry and every outside service replaced by a recorder. They are plain renders of what was written, not screenshots of the team’s tools.

A plain frame showing a contest card’s title, project, year and body with contact details, event, story and photo links — **The contest card**What the step writes to the marketing team’s contest card: who entered, the event, their story and a link to every photo. A plain render of what was written, not a screenshot of the team’s project tool. Local run, invented data.

A plain frame showing a draft bundle’s title, tags, description, products, fields and six photos — **The draft store bundle**What the step asks the store to create: a draft named after the couple, holding their story, the products they ordered in the sizes they bought, and their photos, tagged for the Make This Look collection. Local run, invented data.

A download page titled with a couple and event, two zip buttons and seven file links — **All the media in one click**Each card links to a page that zips the couple’s photos and videos in the browser, or hands over single files. Generated by the step’s own code for an invented entry with drawn pictures. Local run, invented data.

A thank-you email headed Share Your Flair Contest with entry details and what happens next — **The thank-you email**The confirmation the step builds for the couple: their entry details and what happens next. Recorded, not sent. Local run, invented data.

Test runner output listing eleven passing checks in three groups — **Its automated checks, passing**The step’s own 11 checks for link building, the download page and repair planning, run on my machine. Local run, invented data.

Engineering choices

The decisions behind the interface.

Write it as the customer.

The rush email is written in the customer’s voice with the customer as reply-to, so the ticket reads naturally and no helpdesk integration is needed.

Read back every write.

The first run’s writes were all accepted, yet some links were broken and some drafts short of photos. Only re-reading every card proved a clean state.

Neither flow uses an AI model. Both are forms, checks and routing into the tools each team already works in.

Where it stands

One flow live, one still being released.

The rush form has been live since October 2025. Share Your Flair processing has run on every 2025 entry; releasing its media-link fixes and confirming automatic processing of new entries are the next steps.

Same company

More from FiftyFlowers.

FiftyFlowers overview

DIY kit data migrationDelivered on a test copy of the store

Company Second BrainMVP · live since July 2026, two of seven team brains filled

Content EngineIn the company AI workspace since June 2026 · nothing published through it yet

Image StudioIn production · released August 2026

Proposal ManagerBuilt from the team’s wireframes · not launched

Customer service AIIn production · since January 2026

AI Floral AssistantIn the store theme · behind an A/B test since January 2026

Keep exploringSiteSift AI