Jerome

Forum Replies Created

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • in reply to: Calendar select date/time for event #29060
    Jerome
    Participant

    Barry had an idea from another thread that may prove useful*. Perhaps you can create an event for each day (possibly recurring for the Event itself) … then create tickets for each timeslot available.

    Event: 2012-12-06
    Ticket 1: 0900-1000 (Stock: 10)
    Ticket 2: 1000-1100 (Stock: 10)
    Ticket 3: 1100-1200 (Stock: 20)

    It’s just a different way of looking at how to use the system in its current state.

    – You’d have your Calendar showing available Tour Dates that the End-User selects.
    – Your Event would have available Time Slots (Tickets) that the End-User would select.

    May still need further customization and a way to report easily across different types of tickets, but it may be something to consider “in the now” with some more tinkering/ playing around.

    This isn’t one-stop, and involves mouse clicks, etc., but without a lot of developer involvement this may be something to consider.

    * Reference: https://theeventscalendar.com/support/forums/topic/sell-ticket-across-different-events/#post-28749

    in reply to: Feature Requests – All Ideas Welcome! #28682
    Jerome
    Participant

    This plugin is fantastic. I’ve used some other Event Managing tools, and have always wanted integration with WooCommerce. To have two different carts/ checkout systems for Events (non-Tribe) and Products (WooCommerce) is/was incredibly confusing to the end-user. This is miraculous, and out of the box WooTickets comes packaged with everything one would need to get started – and get started successfully. There are a lot of features packed within already that make sense and show the forethought and time spent mapping these out that make WooTickets (even more) unique. Great job!!

    1. Expanding on Additional Fields:
    A. Instead of just showing what is possible/ or “at” the event using Additional Fields. Allow the End-User or Purchaser to select _what_ they would like.

    Example: Additional Field “Shirt Size” with dropdown values of S-M-L. Instead of just showing the Purchaser those shirts are available, they select the size they would like via a dropdown and that information is stored in their Attendee Information. This would help with production costs if items are being made beforehand, you can get a feel for where to spend that up-front cost (To build on that example: 48 smalls, 25 Mediums, 84 Larges ordered before event sales stopped … so purchase/print +10/15 in each instead of trying to guesstimate. With that information available for each Attendee they get what they want with minimal hassle [and could even get their items beforehand potentially]).

    B. Create Forms based on Additional Fields to allow for grouping of Additional Field information to be selected by the Organizer instead of each individual Additional Field.

    Example: 36 Additional Fields created. For Events those 36 Additional Fields coordinate to 6 different “Categories” of Events (or 6 unique AF each). Instead of having the Organizer by-pass the 30 AF they do not care about, they simply select their “Additional Field Form” … and it would display the AF associated with that form. Reducing space, clutter, and potential for Purchaser mistake.

    C. Also if the AF can be sortable or ordered:
    Though with WordPress/PHP knowledge, a developer should be able to rearrange any data they would need.

    2. Individual Attendee Information:
    I know this has been requested, but this would be a great addition for large groups, while still allowing for some N/A if the person isn’t positive who is or is not coming.

    This has the potential to become much more powerful coupled with 1A above (if for example, User A wanted a S Shirt, but User B should get a M Shirt, User C wanted a L Shirt).

    Not to get too crazy, but it would be nice if it was smart enough to map the “Secondary” Tickets to an existing User Account if the Attendee who did not purchase the ticket’s e-mail was provided (or create an account if they did not exist via e-mail [and if First/Last (Given/Family) were required for the Individual Attendee information]). That way, they would be able to print their own tickets (eventually), or get “credit” for purchasing. (If there is a go to 10 Events, get the 11th free type of promotion. Or if there is a Rating/Comment Section for *Attendees Only*)

    Example: User A buys for B/C/D. B/C do not exist but User Accounts are created for them to enable their information to be shown in the Attendee List (and if they would ever want to purchase tickets in the future). User D already exists, so it maps against the Unique Identifier (e-mail).

    Issue: What if 4 tickets are purchased and no information is provided. You do not want to create throwaway accounts. Those tickets all stay in the current format and associated with the purchasing account.

    3. Ticket Queue in User Account Information:
    I know this is being worked on as well. E-mails are sent out to the purchaser via PDF, but if the User could have a repository of tickets they have purchased … well I guess while I’m typing this, that could be handled in an Order History via WooCommerce potentially. It may be nice to have Active/Inactive Tickets though, and the ability to bring them up without the PDF or E-Mail.

    Maybe the ability to “give” their tickets away to other User Accounts as well if they are unable to attend (kind of like the above feature when purchasing for others initially – or finding out their attendee list down the line).

    Kind of Insane Thought: I don’t know if a StubHub like service would like be something to consider to allow tickets to be bartered outside the service (say if it is sold-out)… I have no need for something like that. Ethics and other complications come into play on this one.

    4. QR Codes, or Barcodes, something to help with the sign-in process:
    Though to be fair, I haven’t and will not be able to try the current sign-in process for some time. It seems very robust and quick, and to be honest probably faster than someone scanning a QR Code.

    If there are multiple entry points, this check-in system would/ will be invaluable. So I’d like to see some real world examples before adding in “bells & whistles” to something that probably works pretty well out of the gate.

    It just may make it “look” more secure. And some events may have that ability to handle scanning easily.


    Sorry if this post seemed all over the place. Please reach out with any questions or concerns. Again, this is a great service already!

Viewing 2 posts - 1 through 2 (of 2 total)