Experience setup

Club member access for winery tastings and events

Use club-member data or guest tags to offer member-only tastings, member event pricing, and host-visible member context without promo codes or separate guest logins.

Updated 2026-07-07

Wineries often need guest access to reflect membership, not only table availability. A member may be eligible for a different tasting, a private release appointment, a discounted event ticket, or extra context the host should know before the visit starts.

CoverCount supports club-aware workflows without asking guests to create a separate login, enter a promo code, or use a different booking system. The guest books normally, and CoverCount uses the venue's member data, guest records, or tags to decide what access or pricing applies.

What club member access can control

Use member access when membership should affect the guest experience:

  • Member-only tastings for club pickup weekends, allocation releases, reserve flights, or library pours.
  • Member pricing on Events where the public can buy tickets but verified members receive a lower price.
  • Members-only Events where the page can stay public but checkout is limited to verified members.
  • Host-visible member context so staff can see membership status, tier, preferences, and visit history before the guest arrives.
  • Guest-tag access for groups that are not formal clubs, such as founders lists, neighbors, VIPs, or allocation customers.

Sources for member eligibility

CoverCount can use more than one kind of eligibility source:

  • Connected club or commerce integration — membership data syncs from a supported winery commerce or club platform. Vinoshipper and Commerce7 are current examples. As more winery platforms are connected, the workflow stays the same: CoverCount uses active member records to qualify the guest.
  • Guest tags — staff can maintain tags inside CoverCount, such as Club Member, VIP, Founders List, or Allocation Customer.
  • Manual review — staff can still handle edge cases where the guest is a known member but their booking details do not match the member record.

For guest-facing flows, keep the label broad and familiar. Most venues should use language like Club Members, Wine Club Members, or the name guests already know from the club.

Member access on Experiences

Experiences are best for bookable reservation-style visits: tastings, tours, pickup appointments, patio reservations, and private-link visits.

Common winery patterns include:

  • A Standard Tasting open to everyone.
  • A Reserve Tasting with a deposit or longer duration.
  • A Club Member Tasting for members with different access, benefits, or service expectations.
  • A Release Weekend Pickup Experience when guests still need timed reservation slots.
  • A Private Tasting shared by direct link for selected guests or concierge bookings.

If the visit uses table inventory and guests choose a reservation time, start with an Experience. If the guest is buying admission to a fixed occurrence, use an Event instead.

For starting templates, see Recommended Experiences for wineries.

Member access on Events

Events are best for ticketed or registered occurrences: winemaker dinners, release parties, pickup events, classes, blending sessions, and club gatherings.

Events can support:

  • A public ticket price and a member ticket price.
  • A members-only audience.
  • A public page that advertises the event while checkout verifies member eligibility.
  • Sales cutoffs, refund cutoffs, tax, service charges, gratuity, reminders, attendee lists, and check-in.

For event-specific setup, see Offer member pricing and members-only Events.

Avoid narrow setup names

Do not name the workflow after a single integration unless guests already know that name. If the public page says Vinoshipper members only, the copy may age poorly when the venue adds another club platform or imports a tagged member list.

Better labels:

  • Wine Club Members
  • Club Members
  • Allocation Members
  • Founders List
  • The venue's own club name

Keep integration names in staff setup and internal documentation. Keep guest-facing names tied to the benefit.

Test before publishing

Before opening a member workflow:

  • Test with a known member and confirm the member access or price applies.
  • Test with a non-member and confirm they see the intended fallback: public pricing, a clear members-only message, or no access to an unlisted link.
  • Confirm staff can see the membership context they need on the reservation, registration, or guest profile.
  • Confirm email and SMS messages explain the visit without exposing internal tag or integration names.

Related articles