CiviCRM Community Forums (archive)

We are using civiEvents as a simplified box office for a small theatre company.  Having just completed our first show with civi, I thought I'd take a moment to note my observations and frustrations and to make a few suggestions for some improvements.

Brief background:  After about 1.5 years of selling tickets to performances through a complicated system of paypal, spreadsheets, and quickbooks, we decided last fall to invest some time and money in setting up an integrated ticketing/donation database.  In December, we sponsored some improvements that we needed to make civi useable in our case (CRM-5724 and this drupal module).  In January we uploaded all our historical data and went live with online ticket sales in early February.

Online event registration has been working great for us.  Very few issues and all pretty minor.

We have, however, had a number of frustrations using the backend of civiEvents, especially in the context of selling tickets at the door just prior to the event.  The general issue has been that data entry for "offline" event registration is just not streamlined enough to efficiently serve a queue of people waiting to get into the theater.  The original plan was to use a printed list for folks who were all paid up in advance, and use the admin interface of civi to record new sales and payments on unpaid reservations (i.e. "pending from pay later").  After only one night we were forced to segregate new sales via credit card to a "slow line" and record cash/check purchases by paper.  Within a week we stopped accepting unpaid reservations due to the extra time it takes to apply payments to existing registrations (especially with a CC), and by the end of the run we were recording CC information on little slips of paper and processing them after the performance had begun.

Obviously, this is not ideal.  Recording everything on paper and then transferring the data to civi is both inefficient and error-prone.  Additionally, it makes tracking available inventory (seats) much more complicated.  We even had a couple cases where people bought tickets online just before heading to the theater, only to discover that we had already sold those seats at the door.  Ending online registration earlier prevented this, but because the system had no way of knowing which shows were close to selling out, I had to make a judgement call each night as to when to end online sales and manually shut them down in civi.

Ok, that's the big picture.  And here is my laundry list of suggested improvements in no particular order:

*** Data Entry ***

1. As discussed in this post, it would be very helpful if the event being registered for could be selected at the beginning of the registration process instead of in the middle.  (It occurs to me that one way to handle this might be to pass the event ID in the URL.  This would make it pretty trivial to create a block/menu with links for particular event registrations.)

2. As discussed in the same thread, it would be incredibly helpful if a single form could handle both regular offline registration (for cash/check) and live CC processing.  We had cases where folks changed their mind about payment method during the registration process and we had to start all over.  Very frustrating and slow.

3. Participant role and status should have default values.  Either a) respecting the settings in the online event registration configuration, or b) defined as default in the option lists.

4. I wish the date widget did not appear when tabbing through fields.  Although it only takes a fraction of a second for the widget to materialize, it is still very easy to tab past it too quickly, which results in the widget not disappearing again and obscuring other parts of the form.  99% of the time the default registration date/time is correct.

5. When registering via CC, the contact's billing address should get loaded into the form.  In the absence of a billing address, the primary address should be loaded (since they are the same 90% of the time.)

6. When recording a payment, the "Paid By" field should be required (perhaps optionally required) and have a default value defined in the option list.  Payments that are recorded without this field set make reconciling the night's receipts much more difficult.  (There is also no way find payments with "Paid By" equal to NULL, so finding/correcting them is a pain.)

7. When recording a payment, the "Total Amount" field should default to the total event fee.  We had a number of cases where in the heat of the moment trying to process registrations as quickly as possible this field was left blank.  Making it required would be a small help, but having to re-submit the form adds time to the process.

8. I wish selecting an existing contact and creating a new contact were more tightly integrated and allowed simple editing.  We encountered 2 main problems with the current work flow: a) When registering a new contact, we often had to collect their name twice, once to search the db, and again to enter into the new contact form; and b) Existing contacts cannot be updated without quitting the registration, editing the contact, and starting the registration over again (the most common cases being adding an email address for receipting the event fees and correcting a spelling error).  I'm really not certain how this might be addressed, but it is only the most basic data that would need to be exposed (last, first, primary email).

9. It would sure be sweet to support USB credit card swipers someday.


*** Editing Participant Records ***

10. Multiple payments and third-party payments.  It seems like this is already being worked on as part of "Overhauling Payment Processing for CiviEvents", but I thought I'd mention it here as well.

11. CC payments on pending registrations.  This might be dealt with as part of #2 above, but the current work-around of deleting a registration and starting a new one is most frustrating.

12. Although not as urgent as some other items, it would be nice to be able to edit price set data for an existing participant record.  The challenges raised in this thread might be less of an issue once the one-to-one relationship between participants and contributions is changed (see #10 above).

13. It would be handy to be able to transfer an existing registration to another event (in our case, another performance night of the same show).  This comes up a lot and is difficult in the case of CC payments.  I actually tried this by directly editing the database on my test site, and was surprised to find that it actually worked - the payment followed the participant record to the new event.  Maybe a button or link on the view participant page that allowed (permissioned) users to move a registration to a different event and perhaps changed the civicrm_participant.source field to something like "Event registration transferred from {old_event} by {user}"


*** Miscellaneous ***

14. It would be nice to have a "Paid By" filter on contribution reports in order to make it easy to reconcile cash at the end of the night.  This can be done now with "Find Contributions", but it would be convenient to have a stock report (e.g. cash transactions this day).

15. We are using "admin-only" price set fields (CRM-5766), which makes various discounts pretty simple.  But it would be nice if some price set fields could have non-integer values.  The use case is an admin-only price field for "arbitrary price ticket" or "associated donation" valued at $1 and able to accept, for instance, $12.63.




This stuff is our bread and butter, so yes, we are prepared to sponsor some of these suggestions.  As a practical matter however, we probably can't afford to do them all and those we can will probably have to be phased in.

So I am interested in feedback about this list.  Which items are easy/hard?  Which need to be coordinated with other work?  Which are likely to have unintended consequences?  Which would other folks find useful?  What else might make data entry smoother/faster?

Kirk:

great post and thanx for doing it. In addition to what dave said, would be great if you / we / the community could bring together more folks who use civievent similar to yourself (i.e. a theatre etc). I suspect there are lots of simple things in CiviEvent that we can do that would make things a lot easier and more efficient. The larger things can potentially be group funded / developed

Do post on the blog, we can then use that as a rallying point for other folks to respond to and group together on

lobo

hershel:

would be great if you could blog about the PDF + UPC code and publish the changes you made, along with the custom drupal module that registers persons attendance. Wanna post or blog on it?

lobo

kinda surprising and sad that the client uses open source but is unwilling to return the favor

In the meantime would be great if you could post a detailed description of what you have done along with packages that you used so others can potentially rebuild it with a bit fewer hassles

lobo

> 9. It would sure be sweet to support USB credit card swipers someday.

I believe such swipers do nothing more than input the data swiped. I built an application (unrelated to CiviCRM) that does this and also I have one client doing this with CiviCRM, and that's how it works for both--the worker puts the mouse in the correct field, swipes the card, and the number appears in the field.

Actually, to do card present transactions (lower rate and less chance of a chargeback - the biggest benefit of swiping a card), one needs to read the CVV1 field off the back which is not in the same location as the number. There are specific restrictions on using this data.

We have created an OS X, on site check-in/payment application that we are expanding to work on iOS devices as well. We are trying to figure out how to generalize it a bit, and if we can do that, we will release the source. It allows an event to be pre-selected and is quite fast. We have found it to be much faster than using the web version.