A winery or vineyard website can have several different jobs: provide visiting information, explain the wines, receive tasting enquiries, take agreed online orders or support a wine club. Define which journeys the business actually needs before choosing a platform or commissioning integrations.
This guide is written by No Brainer Creative, an Auckland-based agency working with NZ businesses. It does not claim winery projects in Marlborough, Central Otago or Hawkeβs Bay, and it does not guarantee sales, bookings or search positions. It is a website briefing guide, not an alcohol-sales compliance assessment.
Separate the customer journeys
Visiting and tasting information
Present the real location, visiting arrangements, current hours and contact route the operator approves. Explain whether a visitor can arrive during stated hours, request a tasting or use a confirmed-booking system. Record who maintains changes and how customers learn about a changed arrangement.
Wine information and orders
Agree the product information, imagery, availability and purchase route. Identify the system responsible for orders, payments, inventory and delivery arrangements where those are in scope. The website should describe the actual process rather than imply that every order or region can be served.
Wine-club participation
A membership enquiry, mailing-list sign-up and paid recurring subscription are different journeys. Define the offer, the joining step and any changes or cancellation process with the operator. Confirm which system owns the membership and communication records and who handles exceptions.
Make online-sales requirements part of the approved brief
Online alcohol sales involve requirements beyond visual design. The official remote-sales requirements and relevant regulations are starting references for the operator and its appropriate qualified reviewer.
Do not use this marketing guide to decide which licence, notices, verification or delivery arrangements apply to a particular business. Have the operator supply an approved requirements list and identify who confirms the implementation. A one-click entry screen or an installed feature does not certify compliance.
Review the actual systems before choosing a platform
Inventory the current website, product information, order process, booking arrangements and any wine-club system. Record what works, what needs repair and which data or customer routes must be preserved. A fixed product-count rule does not establish that a managed platform is unsuitable or that a custom build is necessary.
Compare options against the approved requirements, editing needs, continuing costs and support responsibilities. If a migration is justified, plan the useful URLs, content and connected systems that need checking. The website migration guide provides related scope questions.
Use a connection and responsibility register
For every agreed booking, order, payment, membership or notification connection, record the following:
- Starting action: what the customer does.
- Expected state: request, confirmed booking, order, payment or another clearly defined event.
- System owner: where the authoritative record belongs.
- Business responsibility: who acts on the record and maintains the information.
- Exception path: what happens when information is missing, capacity changes or a step fails.
- Verification: the authorised check and observed result, with any limitation.
Agree where messages stop or move to a person when a customer replies, changes a booking or leaves a programme. Do not promote a saved workflow as proof of a delivered email, completed order or continuing subscription.
Prepare content that can be maintained
Use current operator-approved descriptions and imagery. Assign owners for product availability, visiting information and special events. Keep specialised product, licensing and other legal claims with the operator’s appropriate review process. Photography and brand presentation do not establish those claims.
Check readable information and useful contact routes on phones and desktops. Review actual page performance where there is a problem, without assuming every visitor is on a weak rural connection or promising a universal loading threshold. A performance score is not evidence that wine sales or tasting enquiries increased.
Agree the launch checks and handover
Check approved pages and links and each customer journey included in the scope. Any live purchase, payment, call, booking or notification test needs separate authorisation and an identifiable internal-test record. Verify the actual destination and outcome; a visible button or success message is not the same as an order, payment or receipt.
Keep a record of untested items, outside dependencies and who resolves each one. The handover should identify the relevant access arrangements, content-update process and continuing support. Separate the initial build from platform, transaction, message, maintenance and other ongoing responsibilities where they apply.
Talk through your winery website
Define the information, sales, tasting and wine-club journeys that are actually in scope.
Winery website planning questions
Does every winery website need an online shop?
No. Start with the business’s actual sales and visiting arrangements. An information site, tasting enquiry route, online shop and wine-club journey have different requirements. Include ecommerce only where the operator has agreed the scope and responsibilities.
Which platform should a winery choose?
Compare the actual product, editing, booking, order and integration requirements against the available systems. A platform name or a fixed product-count threshold does not establish that a site must be rebuilt. Review the existing setup before proposing a change.
Is a one-click age gate enough for alcohol sales?
This guide does not assess that. The operator must establish the applicable online-sales requirements with appropriate qualified advice and approve the implementation brief. A design feature or a single entry-screen click is not a compliance certification.
What should the wine-club brief cover?
The actual offer, joining route, recurring-payment arrangements if used, changes, cancellations, customer communications and responsibilities in the connected systems. Do not advertise a subscription or automation as operational until the relevant authorised checks support that claim.
How should tasting bookings be described?
Explain whether a visitor is requesting a time or receiving a confirmed booking. Use the real availability process and agree who handles changes or cancellations. A form submission or visible calendar does not establish a confirmed appointment.
What information should product pages use?
Use operator-approved product information, current stock or availability, imagery and the actual purchase and delivery arrangements in scope. Identify who maintains the information and who reviews specialised product or legal claims; design work is not product or regulatory certification.
How do we check the website before launch?
Review approved content, links, phone and keyboard use, and each agreed customer journey. Any live purchase, payment, booking or notification test needs separate authorisation and a clear internal-test record. A success screen alone does not prove the entire order or delivery process.
What should a winery website proposal separate?
The pages and content, design and build, product setup, booking or wine-club connections, migration, checks and handover. Identify ongoing platform, payment, message, maintenance and support responsibilities where they apply. No market price or universal completion window is promised here.
Discuss a defined ecommerce or website scope
Our ecommerce website service explains the broader design and build scope. Bring the current systems, operator-approved requirements and the specific journey you want to improve. No existing wine-club, checkout or booking functionality is assumed to be working without evidence.