Canterbury Faire Booking Deputy Guide

Total Page:16

File Type:pdf, Size:1020Kb

Canterbury Faire Booking Deputy Guide

Canterbury Faire Booking Deputy Guide

Bartholomew Baskin/Peter Hyde, January 2017

Contents Introduction

Since about 2006, CF has used an online booking system which is supported by Peter Hyde/Bartholomew - [email protected] . As a backup, Beth Kent/Ginevra ([email protected]) can also work with it once it's been set up for each CF, and in a pinch Nigel Presland/Ronan also has detailed and skilled knowledge of it from his earlier experience with the system.

Figure one – the beginning of the current CF booking form at http://webcentre.co.nz/SGCantFaire

For various reasons mentioned below, I thought that now would be a good idea to document the preferred bookings deputy handling process required for CF - not just working with information sent by the online system but also communicating with attendees, the CF Steward and occasionally the SG Reeve and SCA NZ Treasurer.

Naturally, future CF stewards and booking deputies may vary the approach, timeline and task-sharing among the team as they see fit. But for a successful event and reporting sequence, the key tasks pretty much have to happen as described.

From CF2017 onwards the online booking system includes support for credit card/Paypal payments. This facility is mainly used by overseas visitors and it greatly lessens the amount of cash handled at gate and eliminates the need for any EFTPOS provision at the event.

On the back of the credit card support, CF2017 also saw an active shift in emphasis to encouraging timely payments from all attendees when bookings are made, as opposed to delayed bank payments or, worse, cash payments at gate. This change was made to lessen overall workload for the stewarding team - especially gate staff - and again to minimise cash handling at gate and its resulting accounting and security hassles.

Apart from the inevitable communication and adjustment pains for attendees, this change was successful, with only a handful of CF2017 bookings paid for at gate – hence almost all the $1700 taken in cash came from 25 casual day trippers, not the roughly 245 attendees who pre-booked. With the cultural adjustment now made, it should be very easy to keep this approach going in future.

Finally, CF2017 also saw the introduction of the GateKeeper software for gate staff. That system is fully described in its own documentation but some reference is made here since it directly feeds off the latter stages of the bookings process and record-keeping.

Timeline and Summary of Key Tasks

The dates below are indicative/preferred rather than fixed in stone. But please bear in mind that availability windows for Bartholomew in particular can impose some constraints, and hurried or last-minute actions can lead to unwanted errors!

Mid June or earlier: CF Steward confirmed, contact Bartholomew asap! Bartholomew will usually ask a small but significant boon in return for his support. Also contact the SG Webwright, as Bartholomew only maintains the booking form itself – the Webwright maintains the CF-related information pages hosted on the SG website, and the various forwarding email addresses (e.g. [email protected] , etc) associated with the event - see Appendix Two.

Mid July, Setup: Convey necessary pricing/timing etc information to Bartholomew - see Appendix One. Booking form and communications testing happens thereafter - see Appendix Two. Ensure that you have a booking deputy in place with reliable access to email and Excel (or similar), and aware of both this document and the master spreadsheet - see Appendix Two. Finally, ask either the past year’s CF’s booking deputy or Bartholomew for a list of all those who agreed to be emailed about future CF’s, so you can promote to them directly once you’ve launched.

2 Early August, Launch: Booking site goes live and can be announced via Pegasus, announcement lists, Facebook, shouting from the rooftops etc. (Seriously: if you want a large CF, it’s virtually all about how well/often you promote it)

August to January, Processing: Main booking deputy tasks: receive and process online bookings, payments and acknowledgements, changes, late payments, refunds or partial refunds, maintain master spreadsheet, etc.

End Sept: First price increment (reminders to lists etc a few days prior)

Just before below: Remind slow payers that payment is required, follow up weekly thereafter (usually very few, but one or two will require more than one reminder before they respond)

End Nov: Second price increment (reminders to lists etc a few days prior)

During December: Ensure Gate deputy is aware of Gatekeeper software and has a chance to try it out - they can contact Bartholomew for an up-to-date version

Ten days before CF: Reminder that bookings are due to close, encourage day trippers to book/pay

One week before CF: Online bookings close – ensure Bartholomew knows well in advance when you want that to happen, and confirm it has happened before finalising

2-3 days before CF, Finalising: Finish master spreadsheet for steward and Gate - especially payment information; send final version to Gate deputy to be used by GateKeeper system

Setup

This is mainly a task for the steward working with Bartholomew and the SG Webwright, rather than the booking deputy - the process is described in Appendices One and Two. But the booking deputy should be involved in at least the testing phase, as (initially-testing) emails will start arriving in their inbox as soon as the email addresses have been properly configured by the SG Webwright.

The key thing about the setup is to get it out of the way early. Getting the website ready for launch is entirely dependent on Bartholomew. This means that the required work might be tightly constrained by his availability if, for example, he is travelling much during the June to August period.

Refer to the appendices for more information on what is required.

Launch

Once testing is completed, these steps need to happen. It's up to the stewarding team which of them are done by the booking deputy vs other members of the team:

* Final checks of the http://sg.lochac.sca.org/cf website content and forwarding of all email addresses used by the booking form (see Appendix Two), especially cf@

* Ask Bartholomew to take the booking form live, and get confirmation that it is – it will be at http://webcentre.co.nz/SGCantFaire although you may prefer to always promote the SG website address above

3 * Publish the event via http://lochac.sca.org/seneschal/database/event/new if it has not happened already (note that there may be a small delay for the group Seneschal to approve the announcement; allow for that!)

* Send full-page event ad to Pegasus if that has not happened already (aim for the September Pegasus at the latest, and all subsequent issues up to January - there's no cost for these ads and they are usually very welcome, especially if well-crafted or graphically interesting)

* Send announcements to (at least) lochac-announce and althing mailing lists, and to relevant Facebook pages the team is aware of - use the http://sg.lochac.sca.org/cf URL for the event website and, if you wish to directly mention the booking form URL, use http://webcentre.co.nz/SGCantFaire

* Sit back and wait for the bookings to roll in - plus occasional dumb questions and Interesting Complications

4 Processing

This is the nitty-gritty. See Appendix Two for details on the various information and communication flows that the booking deputy manages, and merges into the master booking spreadsheet.

Figure two - the first few columns of the master booking spreadsheet

Suggested workflow:

1. At least once a week but preferably more often - especially near the opening and closing of bookings: take the latest cfPerson.csv and copy its new rows into the master spreadsheet. Do a quick sanity-check of each new row: a)delete it if it’s a test or garbage booking – the latter are rare, but happen a couple of times a season b) delete it if it’s identical to the adjacent record – some browsers or users can accidently submit twice. If the rows are nearly identical, you’ll need to decide which one is the correct one, or ask the attendee c)check that total charged makes sense given the options selected, and vice versa - two or three bookings a season have calculation or recording glitches of some kind, for no reason I can fathom. Attendees are highly unlikely to notice those glitches, even if they appear in the emails the booking form sends to them, so you need to notice. Contact the attendee if in doubt.

2. When you get payment information regarding either Paypal or SG account deposits:

a)update the date paid column for each booking record b) if it’s a payment for a multi-person booking, put something like “$123 for 3 people” in the Notes column of the last of their individual records c)record the email address used for the booking d) when all payments have been recorded, send an email like this example to all those whose bookings were updated this session: From: [email protected] Subject: Canterbury Faire Booking confirmed. Content: Greetings, This is just to confirm that we have received notification of payment for your CF booking and hence your booking is CONFIRMED, thank you! If you have any questions or need to make significant changes to your booking, please get in touch.

In service, Xyz CF Booking Deputy

3. If an attendee makes a change request and it’s one you can safely make or which the steward approves: a)modify the booking record in the master spreadsheet as required and add a dated comment about the change in the Notes column b) if the booking value changes as a result, mention the difference in the Notes column too, and please also modify the Total column(s) – including the Running Total - which may also involve altering the running total of any subsequent rows which belong to the same booking! c)if an extra payment is required, ask them to make it with the same CFnnnnn booking code reference as their original booking. If they originally paid via internet deposit, tell them to use the same bank information they got in their first booking email from the site. If they paid via Paypal, see Appendix Three for notes about how they can pay the extra and also the calculation effects of the Paypal surcharge. d) if a partial or full refund is required and they paid by internet banking, ask for their bank account details and then email those to [email protected] with an explanation, CFnnnnn booking reference and refund amount. If they paid via Paypal, email [email protected] with the

5 amount, CFnnnnn booking reference and refund amount (the Treasurer can find the Paypal account (email address) used for their original payment and send the refund to that). Ask the person to get back to you if they don’t get their refund within a week. e)cancellations should be marked with “CANCELLED dd/mm/yy” in the Notes column and turn the row colour red. Such records can be kept in the master spreadsheet (especially while there is a refund still pending) until the final copy of the master spreadsheet is prepared for Gate staff –though there’s no big deal if you don’t delete them then either

4. when the final price rise is imminent, make a list of email addresses of those who have booked at least a week ago but haven’t yet paid, and send them all an email based on the one below – but do edit the bit about resources to suit! It won’t be many people, and more than half will respond quickly (most making payment and a couple asking for a grace period). One or two will need a couple of weekly follow-ups before they’ll reply.

From: [email protected] Subject: Your CF booking payment is due Content: Greetings, Please ignore the rest of this message if you've made payment for your Canterbury Faire booking in the last couple of days. And if you've made payment earlier than that, please reply to me immediately with payment details (date, target account number, reference) so I can track it down - because I must have overlooked it, sorry!

== CF booking - payment due

This year we are continuing the system of "payment due with booking", to ensure the fair allocation of resources and costs, and to better balance the workload for the stewarding team. We are very grateful that virtually all attendees have been paying as soon as they make their booking.

Resources at CF which are normally scarce - tents and mattresses - are now all running out, and feast bookings and T-Shirt orders are already closed. This means that new, paid bookings will have to take precedence over old, unconfirmed ones.

Thus, if you have made a CF booking and want to confirm your attendance (and make life easier for the stewarding team), please locate the confirmation email you originally received and make payment today, thanks very much!

If you have hardship reasons for delaying payment for an extra week or so, please DO get in touch - we can handle one or two such cases and certainly would rather do that and still get to welcome everybody to CF in a month's time!

In service, Xyz CF Booking Deputy

5. Around two weeks before the week – preferably in the first week of January – send a copy of the current booking information to the gate deputy, who can easily use it in Gatekeeper to generate a “by the way, you need to renew” notice to those who booked as members, but whose memberships have since expired. Alternatively, agree with them to do this yourself if you have access to a copy of GateKeeper.

Finalising

The information in the master booking spreadsheet is crucial to the CF steward and several deputies and especially to the gate deputy. The CF steward and gate deputy should both get interim copies as the close of bookings draw near – at least a couple of weeks ahead - and a final copy when final payment information has been received and processed - preferably two or three days before the event starts. Especially in the last week, it’s very important that the steward and any others who might be contacted directly by attendees know that you need to know of changes, e.g. shuttle or meal plan bookings, that will affect booking and gate records. Best practise is that requests are always forwarded to the Booking Deputy, even if the actual response comes from another officer.

6 The final steps include:

 Deal with any waitlist requests for the feast, if noted and if feast slots have opened up due to cancellations or steward flexibility

 Ensure the spreadsheet is as up to date as possible, with all last-minute booking records, all revisions and all payments entered

 Run down the Balanced Owed column and enter in to it any remaining unpaid sums OR (as negative numbers!) any refunds that need to be issued in cash to attendees by gate. Try to minimise both by dealing with payments and refunds as early as possible in the booking process!

 Review your Notes for each record as well, in case something was overlooked

 Ensure that the steward and gate deputy both get a copy of the final spreadsheet, and the steward also gets the final copies of cfExtra.csv and cfGroup.csv

 If any late payment information is received, ensure the CF Steward and gate deputy are told about it and consider issuing a new "final" version of the spreadsheet if gate has time to deal with that. Should be easy.

Appendix One - Booking Form Configuration and Testing

Below is the information and testing process required to configure each event's booking form and take it live. Most of it is very straightforward, but most of it does need to be fully locked in before you can open bookings. Minor variations from year to year (e.g. whether or not to offer a T-Shirt or scrip bag) are easy, as are useful wording changes. But significant changes to the booking form’s functionality or options are hard to do, hence discouraged, unless they are discussed very early in the process.

When you first contact Bartholomew, he'll put the previous year's form online so you’ll be reminded how it looks and works, which will help guide your decisions below. Once you supply all the needed information, he'll update it to reflect that, at which point pre-launch testing can begin.

Once the sample booking form is available at http://webcentre.co.nz/SGCantFaire, play as much as you like but don’t submit it until you are sure that the email forwarding has been set up for your event team (see Appendix Two). Otherwise, spurious emails will go to members of the past year’s team until all those forwarding changes are made. One workaround for this is to ask the SG Webwright to set all of them to forward all of them to you until all your team members are in place.

Remember that the h ttp://sg.lochac.sca.org/cf subsite is entirely controlled by the SG Webwright, Bartholomew only does the booking form. That includes anything on that site which the form links to, such as site map, t-shirt design jpg – please talk to the Webwright. The t-shirt design, once decided, needs to be put online by the Webwright here: http://sg.lochac.sca.org/cf20xx/tshirt.jpg (where xx is the year number).

Below are the settings you need to adjust and provide to Bartholomew so he can update the form for your CF. The list is provided in the form of macro settings and related comments from the booking form application. Bartholomew won’t mind how you get it back to him so long as it’s clear, complete and in plenty of time.

// Event Prices and dates //======mcCFInitialCloseDate=12 January mcCFFinalPaymentDate=12 January mcCFEarlyDate=1 October mcCFLastPriceRiseDate=1 December

//before 1 Oct (second price is for children, i.e. ages 5 to 15): mcCFEarlyPrice=135 mcCFChEarlyPrice=67.50

7 //before 1 Dec mcCFMidPrice=145 mcCFChMidPrice=72.50

//on or after 1 Dec: mcCFFullPrice=155 mcCFChFullPrice=75

// bunk price is full-event only, even if they are needed for only a couple of nights mcBunkPriceFull=25

// per pair of mattresses, capped at the second price if full event: mcMattressPrice=2 mcMattressCappedPrice=15 mcTentPrice=35

// not used at present - the issue is “will hay actually be available then, at that price”? mcHayBale=4

// Shuttles (or buses) // Price is each way, can apply to buses if not offering shuttles: mcShuttlePrice=25

// if they want different pickup or dropoff (each way) – not applicable if buses mcCFShuttleExtraPrice=20

// Group names and contact emails of camping areas – for more info see // http://sg.lochac.sca.org/docs/CFLandAllocation.doc - the general rule is that the steward // or deputy should contact them to at least get an estimate of numbers before doing any new // site map. Plus, that act confirms the email address is still the right one, because a // household leader IS EMAILED when someone books and indicates their household. Note that // the land allocation guidelines don’t allow a household to opt out of getting these emails – // the process exists to allow the steward to avoid being dragged into within-group // land allocation discussions, and to prevent any misapprehensions by people intending to // camp in an area.

Group Name Contact Heorot [email protected] Northside [email protected] Cultus Faunus/Domus Canem [email protected] Amberherthe [email protected] Draco Viridis [email protected] Ordo Cygni/KAOS and Friends [email protected] Darton [email protected] Ildhafn [email protected] Il Campiello [email protected] Nelsoin Medieval [email protected] Wyvern Guard [email protected] Curvus Domus [email protected]

Once Bartholomew has correct information for all the above and has entered it into the system, he will tell you that testing can commence. Again, you shouldn’t start submitting the form until you have confirmed with the Webwright that email forwarding has been updated to reflect your team.

Even without submitting the form, you can review the text and options offered and ensure that the calculations all add up correctly based on the options selected. Test a wide range of scenarios and take care not to neglect under-5s, children and young adults, for example.

Once you are able to submit the form, also look for correct content in emails and emails going to the right people (especially the booking deputy and other key deputies such as food plan coordinator).

Finally, a bonus – mentioned here because it involves getting information to Bartholomew. Bartholomew also typically takes care of the hourly village bells at CF. He can also arrange for pre-scheduled trumpet fanfares at fixed times - one steward used these 20 minutes ahead of all scheduled heavy tournaments and wars, to try and help the fighters be on time. Subject to availability, random other sound effects may be possible if they enhance the event – such as the elephants heard a couple of times at CF 2017. But mostly this: one of the steward’s perks is that you get to choose the closing-down tune which is played just before the bells are dismantled on Sunday morning. Just send

8 Bartholomew an MP3 or WMA file of your preferred music well before the event. The default that will be used if you provide nothing is Louis Armstrong’s "Wonderful World".

Appendix Two - Information Flows, Emails and Spreadsheets

Information Flows

The booking deputy’s main task is to combine four key information flows into an accurate master spreadsheet:

1. Booking emails from the website – there will be at least one per person, and one per group (even a single person booking will generate a group email). The content of these emails is good for quick sanity checking, but the attachments are what matter most to the booking deputy. More on these below.

2. Payment confirmations from Paypal – these may be emails forwarded from Paypal for each transaction (in which case you’ll get one per successful Paypal/credit card booking). But it’s possible that for security reasons the SCA NZ Treasurer will instead decide to send you a regular report of all such bookings received in the past two weeks, month or whatever, with a final update just before CF. The notification approach needs to be agreed by the CF Steward with the Treasurer before bookings open – see Appendix Three for some background information.

3. SG bank deposit information covering internet payments and cheques deposited. You could be given a read-only login to the SG account check this online yourself. But far more likely it is provided as a PDF of recent transactions by the SG Reeve or a deputy on a regular basis, e.g. weekly or two-weekly, with a final update just before CF. This needs to be agreed by the CF Steward with the SG Reeve before bookings open.

4. Change requests from attendees, whether adding flight/shuttle info etc, altering their requirements, or cancelling entirely

The booking deputy may also receive a handful of mailed cheque payments. These need to be deposited reliably, and a good record needs to be made before each deposit happens because the bank statement won’t clearly identify the source of a cheque deposit. Fortunately, cheques are now rare enough that a record-keeping lapse can usually be accurately covered by looking at the timing and the amount.

Emails

The website sends numerous emails when bookings are made - not just to the booking steward. For this reason, it is important that the SG Webwright is asked to “forward” the addresses below to the appropriate people and that this forwarding is tested before booking opens. In particular, the first two addresses are essential, both because they are widely published (e.g. in event notices) but also because they are critical to CF communications and the booking process in particular. Some of the less important addresses could just be forwarded to the steward, especially if bookings open before the relevant deputy is appointed. [email protected] the steward (it may also be wise to forward cfsteward@ to cf@, just in case) cfbooking the booking deputy (cfbookings@ is also supported - only need to change cfbooking@) cfshuttle@ …when someone books one or more shuttles cffood@ …when someone books for meal plan or feast (including their health info) cfaands@ …when someone proposes an A&S workshop cfhiregarb …when someone books hire garb cfmarket@ …when someone says they are interested in market space cfbillet@ …when someone requests billeting assistance cfmusicians@ …when someone offers to play for the ball etc. cfchildren@ …when someone offers to help with a childrens’ activity

..plus these standard SG officer email addresses, who may or may not be the responsible person for your CF: chirugeon@ …when someone volunteers to help with first aid duties constable@ …when some volunteers to help with site security herald@ …when some volunteers to help with this role lists@ …when some volunteers to help with this role

9 marshal@ …when some volunteers to help with this role

Several of the deputies will be pleased to get the emailed information from the word go, e.g. food people getting an idea of allergies or the shuttle deputy roughly assessing shuttle needs etc. However, it is not essential that such deputies or record every notification email themselves. That’s because it is always possible to compile a final, complete list of any such information from the master spreadsheet.

Furthermore, the master spreadsheet will accurately reflect changes and cancellations made during the booking season, whereas such changes won’t be auto-notified to the deputies via email because the changes are made manually in the spreadsheet by the booking deputy rather than by attendees through the website. In other words, the true and accurate record of requirements for the event is the master spreadsheet, not the information compiled by deputies from the automatic emails that they get. The event steward should make sure that key deputies know this, and ensure that they get the accurate and up to date record when they need it!

Spreadsheets

In addition to notification emails, the site actually generates three comma-delimited (CSV) files, each of which can be loaded directly into Excel (or similar) as required. They all continuously grow with each new booking and, as each new booking is made, they are all emailed to the booking deputy as attachments to either the individual or group notification emails that the booking deputy gets. The first file, cfPerson.csv, is by far the most important. It feeds directly into the master spreadsheet by simple cutting and pasting of new rows from one to the other each time there are new bookings.

A template for the master spreadsheet is maintained at http://webcentre.co.nz/CFMasterSpreadsheet.xls - I strongly encourage you to use it. The copies of CFPerson.csv supplied by the site will grow continuously – and will even retain copies of bookings which are spurious (e.g. people playing with the form) or subsequently cancelled. But the master spreadsheet should reflect the actual state of bookings – edit all booking records there and there only.

The remaining two CSV files are far less important than cfPerson:

1. cfExtra holds merchanting requests, A&S & Children’s class offerings and offers of site help – all of which are non-critical, almost never change, and could be readily compiled by the relevant deputies from their notification emails rather than depending on the spreadsheet. For this reason, I chose not to make and maintain a “master” copy of this one during the booking season. This means that, at the end of the season, the final cfExtra - perhaps including some spurious records - is “it”. Naturally, a few minutes of manual comparison with the master spreadsheet would allow such dud records to be found and deleted, if anyone thought it mattered.

2. cfGroup.csv is even less important, and for the same reasons it also has no “master” copy. It holds a record of people in a group, where they are camping (assuming they are), and their billeting requirements if any.

For CF 2017, the stewarding team found it handy to maintain a shared copy of each of the spreadsheets, on the clear understanding that only the booking steward updated them! This was very easily done via Dropbox, and any similar file-sharing service could be used provided the key deputies all agreed to sign up to it. In the case of CF 2017, for privacy reasons the spreadsheets were only continually shared during the booking process by the steward, booking deputy and perhaps one or two others decided by the steward. The steward can always create and provide cut-down portions of the spreadsheet(s) to others if required.

The files shared were cfExtra and cfGroup (i.e. the versions attached to the newest booking emails from the site) and the master spreadsheet (updated by hand from the cfPerson attached to the latest booking email from the site, plus the other information flows mentioned above).

Finally, a word about statistics and and reporting. In Excel, the COUNTIF formula is your friend. It’s simple and versatile, as is its friend SUMIF – both are well worth learning if you don’t know them already (minor cavet – for as long as CANCELLED bookings are kept intact in the master spreadsheet, COUNTIF will still count those). For major bonus points, learn how to make a separate CFReport spreadsheet which references the data in the (ever- accumulating) master spreadsheet. It can display up-to-date stats on money, resource bookings etc etc without having to place formulae into the master spreadsheet. Because, after all, only the booking deputy should be touching the latter!

10 Appendix Three - Paypal

The information below is excerpted from a report sent to SCA NZ after Paypal had been in use for several months - it covers the main issues associated with its use. Some of these are relevant to CF and others may be more useful to someone planning a non-CF event and wondering whether or not (or how) to offer the Paypal/credit card option.

Paypal for CF Bookings, Dec 2017

Of the 210 attendees booked to date, a quarter (54) opted to pay by credit card/Paypal rather than internet banking or cheque (five used that last option). Unsurprisingly, almost all those using credit cards were overseas residents, with only a couple of locals in the mix.

In two cases, the attendees experienced problems with Paypal while making their original booking; these were dealt with later without much trouble – see Process Issues below.

The value of bookings via Paypal is just under $15,500 which is slightly more than 1/3 of the total booking value to date.

Of the overseas bookings, three or four selected the internet banking payment option on the booking form rather than Paypal/credit card. In at least one case this was deliberate because they hoped to actually pay at the gate as per previous years. The others seem to have overlooked the Paypal/credit card option. Dealing with these errors was one of the fiddlier tasks associated with the new payment option – see Process Issues below – but not too onerous.

Recommendations

• There is every reason to continue offering the Paypal/credit card facility via the CF booking form in future. There was almost no resistance to the 4% premium it required and the administrative effort involved in processing the bookings was little more (and usually less) than handling bookings paid via internet banking or cheque. Plus there is good value in both workload and financial terms in the timeliness for these and all other payments that resulted.

• It may be worth offering this payment option for other large events where the price per head is relatively high and international attendance is more than a few people - such as Crown events. However, the administrative effort involved in doing so needs to be balanced against the benefits to the event and the attendees of not having to take cash payment at the gate from the overseas visitors. (Note: it is entirely possible to offer this facility without requiring a special booking form, by using the after-the-fact payments approach described in Process Issues below).

• There's no need to consider offering this option for SCANZ memberships, though it's not very difficult in technical terms. That's because virtually all the Kiwis paying their CF fees opted to use the less convenient internet banking rather than the Paypal alternative with its 4% premium. I'd expect very similar behaviour if this option was offered for SCANZ fees - even though the surcharge would amount to much less on a $15-$30 membership.

• For similar reasons, there's no need to consider offering this facility for events which have substantially or only NZ attendees.

• The payment confirmation process has worked very smoothly for this event because, as CF Booking Deputy, I was getting automatic copies of all Paypal-related emails, including such confirmations. On a couple of occasions the payment confirmation emails were delayed by 2-3 days but for all the others they were immediate. That said: for smaller events at least and possibly for CF also, I recommend an approach whereby the Treasurer instead sends a periodic (e.g. monthly) report of payments received, rather than all the Paypal emails being automatically copied to the event's booking deputy. This more secure approach would be sufficient for the event and should not pose too much of a burden for the Treasurer.

Process Issues

This section is presented not because it was a big deal but for the sake of those who have to handle this area for future events - specifically the booking steward and, to a lesser extent, the Treasurer.

CF attendees sometimes book while some aspects of their plans are fluid (most often shuttles vs. friends picking them up) - and then request amendments later. This creates a little extra work for the booking deputy. This situation also arises where people make errors on their booking form. For previous CFs, the relaxed payment schedule usually

11 meant that refunds or top-up payments weren't often needed, because quite frequently payment wasn't made until after plans were finalised.

This year, the fact that credit card payments were happening immediately meant that the stewarding team also found it easier to encourage more-timely payment for local bookings. This resulted in less work overall for the stewarding team and especially gate staff. (It can also be regarded as fairer than the previous scenario, where someone could book early - and get the benefits of doing so - yet still pay very late or even at the event, while people who booked later and paid immediately might pay significantly more and also miss out on scarce resources).

In spite of their benefits, timely payments do mean that amendments and cancellations have resulted in the need for a few top-up payments or refunds.

Specifically, thus far there have been:

• three cancellations - only one required a Paypal refund; the other two were unpaid NZ bookings hence had no admin consequences

• one partial Paypal refund due to a calculation error on my part relating to an amendment they had made

• at least four cases where manual, after-the-fact Paypal payments of the full event fee have been needed - whether because the original Paypal process failed (two cases) or because the overseas visitor mistakenly selected internet banking rather than Paypal as their payment option, without having any means to make an NZ internet deposit

• at least two amendments which required an additional top-up Paypal payment

The single cancellation involving a Paypal booking was straightforward - a simple request with sufficient detail was made to the Treasurer who handled it without complications.

The partial refund took the Treasurer more time because Paypal doesn't have a mechanism for a part-refund; he instead used Paypal's distinct (but straightforward) Send Money facility to handle the refund and this will be easy to use for any future cases. But see the note about the 4% calculation below, because it applies to part-refunds also!

After-the-fact full payments were relatively easy also - in each case the user had to be instructed to log in to Paypal and use its Send Money facility to make payment of $NZxyz.00 to [email protected] with the appropriate CFnnnnn reference. Thus far, all attendees have been able to do this successfully - in one case by transmitting a "Paypal eCheque", the latter being was less onerous for them and no issue for us except for a few days additional delay. These payments were very easy to identify and confirmed through the usual process.

A complication for after-the-fact payments may arise in future where an attendee doesn't have a Paypal account and doesn't wish to create one just to send us money in that way. Provided event prices haven't gone up in the meanwhile, they should be asked to just resubmit their booking and pay via the online booking's Paypal option, which doesn't require them to create a Paypal account.

Not tested: a viable alternative may be to ask the Treasurer to use Paypal’s “Send Invoice” feature to email them a payment request which they can also pay via credit card without actually creating a Paypal account. And if that's no good, a future event steward would probably just opt to let them pay cash at gate, since such cases are very rare (none at all this year). If so, remove the 4% surcharge first!

A final complication for after-the-fact manual payments is the 4% premium which must be added if their original booking had the "internet banking" payment method selected - because they'll actually be paying via Paypal with its extra costs. The tricky part is remembering to apply the 4% when telling them how to make the payment manually (and also remembering to appropriately modify the relevant dollar values in their booking record, so that the event steward and Reeve don’t get flummoxed by the discrepancy later).

Top-up payments or refunds due to errors or amendments are the hardest case, simply due to the additional calculations required. Amendments themselves usually lead to complications (“add this”, “remove that”) and the 4% fee that applies on top of the published price for each item is an additional gotcha that must be kept in mind for both additions and subtractions. Those aspects aside, they are no harder than the full after-the-fact payments described above.

Funds Transfers between SCA NZ and Group

12 The actual transfers of funds from SCA NZ's Paypal account to the group's account is something to be negotiated between the Treasurer and the group Reeve. Note that the transfers need not be tightly tied to individual bookings, and in fact I strongly recommend against trying to do that. They should just be round numbers transferred at an agreed time each month, with a final clear-up transfer made a few weeks after the event closes (that delay catering nicely for any post-event refunds which might be required for some reason).

13

Recommended publications