Hi all,
Was reading lobo's latest blog and I'm almost sure that with these improvments we can have an event smoother event registration. The workflow would be:
1) You create the event
So far so good, same as before
2) You are sending it to some groups using send to mail or civimail.
To have the highest response rate, you need to put in the subject and body the detail of the event (the title, location, date, description, registration link...).
Until now, it involved a lot of copy paste between the event page and the email to be send... or doing it the inefficient way "dude, I'm too lazy to give you the detail on the email so you can figure out what it's all about directly, but click on http://www.example.org/civicrm/event/view?id=42 and you'll get that info"
Beside being cumbersome, it also introduced errors, because the invitation was saved as template, reused but not properly update (eg. you forgot to update the id of the event and end up in the wrong registration, the date was incorrect...)
With the proposed improvment, you would have a template invitation where the proper information is fetched directly from the event thanks to new tokens:
-------------------------------------
Dear {contact.firstname},
I would like you to attend to the event "{event.title}".
Where? {event.location}
When? {event.start_date} until {event.end_date}
More info and map {event.url}
You can register online {event.registration_url}
{event.description}
-------------------------------------
By choosing a template that contains an event token, the mail form will have a new field "event" displayed where you can choose for which event (from a list/autocomplete of upcoming events) that invitation will be customised and so {event.title} contains the right title after the merge in the email sent.
3) The recipient receives the email.
The email contains a special hidden attachment (VCALENDAR), that contains the details of the event invitation in a computer readable format that both gmail and outlook understand (and plenty other mail clients too).
The mail clients display that invitation (in gmail, as a box on the top left corner of the mail)
| Title: | Event title as put in civiEvent |
| When: | Thu 24 Mar 5:45pm – 6:45pm (CET) |
| Who: | demo@tttp.eu* |
| more details | |
|
Going? Yes - Maybe - No
|
By clicking on the yes Maybe or no, the contact is automatically added as a participant with the proper status.
4) Sending a "made up your mind?" email one week before the event
Sending a reminder to the ones that did click on "maybe" and that haven't clicked on yes or no. This is done automatically now.
5) Sending a reminder the day before the event
For all those that have clicked yes (or registered online via the form), send a reminder. This is done automatically too, and event organising is becoming less stressful.
6) Name badges
You can generate the name badges and print them the day before the event, without having to get interupted by having to send the reminder (cf point above) and you are feeling more and more happy.
7) Register the attendence during the event
TTTP has developped an external drupal module that provides a searchable list of participants. There is almost no waiting at the registration desk, each person give her/his name ("Arthur"), you type it and the list is filtered to it contains only the Arthurs', you click on the status on the right line (Arthur Dent) and the status changes from Registered to Confirmed without leaving the page. You give the badge and are ready to register the next one. That's so easy that you are almost laughting remembering the mess it was before civi.
8) Sending a thank you after the event
The list of participant is already updated, the prepared templated message is sent automatically two hours after the event, while you are sipping a cup of champaign with the participants that congratulate you on how smoothly the event was run.
I'm pretty sure the make it happen covers this above points. Lobo, could you confirm ?
If you want to have events as easily run as what presented it, pick up your credit card and make it happen Event a small amount will help.
What's missing in the picture ?
The only points that aren't covered are:
1) being able to complete the "yes, I'm coming", and fill the details that are specific to the event (eg. if you want to register to a workshop, a dietary requirement, the arrival date...).
2) pay for the paid events
This would mean being able to let the participant update an existing registration. That has been a requested feature in the forums. Should we try to make it happen too ? Please comment if you can commit to fund part of the dev.
Comments
We use events a bit differently as we use them for classes & would want to invite people to several events at once - which would seem to fall outside the current plan.
However, the sort of e-mail we would want to automate would be a link to people to pay their pending registrations with a link to their pending registrations.
At the moment you can send links to people to complete pending registrations - you just copy the waitlist url - I think you add pid=participant_id from memory to the URL. It creates a new contribution rather than completing an existing pending one. This is problematic because if you cancel the original pending one it cancels the event. This is all pretty inter-related to the accounts initiative so I haven't wanted ot get into it too much until that is progressed as the way payments are recorded will change a little.
On my to-do list is request to have people added to an organic group after an event has finished. It is supposed to be only those who attended but I expect it will be enough to add all & let the admins remove manually. Haven't started on this yet
Hi,
Don't think they are token related to the participant in the scope, but shouldn't be difficult to add some that are {participant.status}, {participant.id}... (eg. you know the event and contact, can find the participant too).
X+
If I understand you correctly, the tokens would exist as tokens up to the point where the email is sent. I think this would be counterintuitive for most people. The purpose of tokens is to replace text on a per-message basis, not a per-mailing basis. In other words, the substituted values will be exactly the same for every message sent, therefore they do not need to be tokens.
A better solution would be to use those tokens when designing the message template, but have the tokens get replaced when the template is loaded into the message editor. That way the user can see exactly what they are sending, and will have better control over the message and a better overall experience.
Hi,
For a contact.*, that's per contact, hence per email sent. For an event.* that's per event.
you could in theory generate it per email sent, but as it won't change between the first and the last email, sounds more logical to do it per mailing.
I am not sure what you find confusing in that, your issue of not knowing exactly what is sent is the same for a contact.token than for an event.token, isn't it?
Moverover, if you do the token replacement before the save, it means you can't save a new template/update template, as it won't be a token anymore.
I'm trying to look out for the overall usability of CiviCRM, and this seems like an obvious pitfall.
Unless you're talking about sending out event messages completely unmanned (i.e. the message is generated and sent automatically when the event is created with no user interaction), then tokens don't make sense here. They can and should be part of message templates, but as soon as that template is loaded into the editor the tokens should already be replaced, so the user can see exactly what she is sending, and can edit in an intuitive fashion.
It's pretty common to want to tweak the text of your email (embellishing the name, giving more specifics about the dates, etc). And I think useless tokens would just get in the way.
My $.02
I see your point. wondering if an "expand/replace event token" (or whatever it's named in the word processor) button wouldn't do the trick ?
You get {event.title} that is transformed into "Conference and Dinner gala in Beiruth"...
Something that would actually be quite easy to do with ajax & api v3...
X+
1. Note that we generally send out a calendar of events in the email. We often announce a single important event too but always include the upcoming events.
2. Reminder should be based on registration close not event date.
3. For #6 Badges, should also manage attendance so we can know who showed up (and ensure only 1 registration per person). Also, should be optional for #7 so people it only goes to people who showed up.
4. Additional event tokens to concider: price, price set, early bird discount, participant listing (or link to "see who's coming")
As looking through several forum posts. I think an extra plus to the workflow of the event registration process would be the ability to be able to add a relationship from the admin page to link the profile on the top of the page and the secondary profile.
Hi,
Not sure I understood you, you mean between the main contact and the additionnal one, right ? (the top and bottom profiles always refer to the same contact/participant). My experience is that the rules are complex, and depends if the contacts exist or not, and for instance the gender of the second participant or her age (to know if you go for partner or child of) and might want to create an household beside creating the relationship...
I think this is better handled by a custom module where you can implement all the complex rules that you need.