We've just set up one page giving and we have thought of another use for the page. The intention of this procedure is to discontinue verbal collection of credit card details by phone.
I'd like to run this up the flagpole to see if anyone sees any pitfalls. I'd be grateful for your thoughts on this proposal:
Set up a separate "On Account" type for ticketing funds.
Set up a contrib type that would utilize OPG to accept payments to the new On Account.
Style the One-Page Giving form and confirmation for this contrib to refer to "Payments" rather than donations.
After creating a customer record if needed and verifying the primary login, our staff could then verbally direct customers to the new OPG page.
Guest fills out first, last and email using the primary login. (our logins are email addresses) Guest inputs the amount to pay, as instructed by our staff, and proceeds to Windcave hosted payment page.
Upon completion of the payment, our staff can then see the money On Account. They can then use the On Account funds to complete a reservation and send PAH tickets and confirmation as usual.
much thanks,
Kate
Hi Kate,
Thank you for sharing this procedure with the community, as the Business Analyst for consumer-facing products here at Tessitura, I love hearing about unique ways that our members are leveraging One-Page Giving and other TNEW features.
From my perspective, your procedure seems straightforward, although you do have to trust the customer to input the right amount. But you could absolutely customize the properties to show it as a ticketing page as you have mentioned.
I would love to hear about how this works if you end up implementing it, thanks again!
Paul
Kate,
We are just discussing doing this exact process to collect payments for Comm Ed programs like Lectures/Tours/School Shows since we don't require payment up front for those! The hurdle we are trying to think through right now (which is probably easier for individual ticket buyers), is the process for getting the On Account payment onto the Constituent with the original outstanding Order, since the person filling out the One Page Giving page is creating a new Guest Checkout record. We could build in an extra day in the process to merge the Guest Checkout account with the original account before processing, but for Comm Ed programs, that will mean we'll constantly be merging individual accounts into School or Organization records, which I feel could get messy.
But if you are just merging two duplicate individual records, it seems like this should work great! Exciting to hear we're not the only ones thinking about this!
-Lily
We don't currently allow guest checkout but since we'd be instructing the payer to use the primary login email, I don't expect duplicate accounts at all. As I understand it, OPG matches the email used on the page to an existing account which has that primary login.
So your teachers could use the email login where the order has been reserved. There is no password so I guess people could make payments on other people's accounts (the school's account in your case).
We also talked about doing this earlier this summer! We opted not to, primarily because we don't have a ton of installment billing patrons so it wasn't really worth the work to set it up, but I'd be very interested to hear how it works out for you!
To help the patrons input the right amount -- the url for donate pages can have amounts embedded in them, so if you are sending email reminders to your patrons to make payments, the link can have the amount embedded. If patrons owe different amounts (such as installment billing) you could potentially export the amount due in your mail merge prep and use that amount as a merge field at the end of the url (with no spaces) so the URL in the email would end with donate/q/[slug]?amount=[mergefield]
Although that's with the disclaimer that I've had trouble getting those fields to export cleanly - I had to write some SQL to do so.
Thanks for this tip! I am excited about this possibility for collection of $ for group sales.
Oh I love that idea!
Hi Anna-
It sounds like you did a lot of great work with SQL and mail merging, really great to hear about. One point of clarification is that while you can set the suggested amount for a One-Page Giving page in your configuration of LTR_TNEW_CONTRIB_TYPE, the ?amount parameter is not supported, however you can use ?promo to populate a source number.
Kate Schmitz said:I'd like to run this up the flagpole to see if anyone sees any pitfalls.
The obvious ones would be "I don't do those computer things" and high-touch VIP constituents. We couldn't go to not taking cards on the phone for our high-level donors, who very frequently call simply to update their card numbers/expiration dates.
Oh thank you for catching that Paul! Our original work on that was before one-page came out so glad to know we'd still have to use the standard contribution page if the embedded amount is an important step for us.
Thanks. That's certainly a consideration.
Back-story: We are trying to keep our telephone call center out of scope for PCI requirements because we are finding that a PCI-compliant call center is an expense we can ill-afford right now, with visitation rates down. We plan to use a POTS line for the occasions when a patron cant or wont, or just needs TLC.
The One-Page-Giving function is really simple though, so we are hopeful that most folks will not balk.
This is our plan for schools that have been invoiced. When they come to confirm they will come to the OTG page and enter in the amount on their invoice, that goes to on account and we'll pay the booking off
I found one 'gotcha' for my plan. We did not plan to require addresses for this OPG form but it appears that it is required to collect the address because we require an address for creation of a constituent account in T_DEFAULTS. I'm sad because this make the form much longer to complete and would cause a bunch of duplicate addresses to be created.It would be cool if there was a separate setting for OPG vs.ticket sales or standard donations.