Randall (Randy) Rensch
My feedback
81 results found
-
163 votes
An error occurred while saving the comment An error occurred while saving the comment Randall (Randy) Rensch
commented
Yet more reasons for having a web version of each major email:
Some emails cannot be delivered for technical reasons. Re-sending doesn't work. We can personally send those people an email from a personal account, but forwarding one is potentially problematic (spammy, technically difficult, wrong personalization, etc.). The situation calls for a simple email saying "We were unable to deliver to your address. Yada yada. Meanwhile, you can see the email here: (url)"
Some people have opted out of receiving certain emails. But they might nevertheless want to see them. It would be nice to have a menu of them on a page they could visit or we could refer them to.
By the way, any web version that remains online for long should be editable or annotable. Typos happen and plans change, so we should be able to correct the archived version and be sure it's current.
Randall (Randy) Rensch
supported this idea
·
-
35 votes
An error occurred while saving the comment Randall (Randy) Rensch
commented
A multi-faceted issue, and an important one. Losing subscribers is not a peripheral matter.
1. There are two different types of email lists. Although the distinction between Automatic Event Announcement and Manual emails is surely lost on most users, it exists. And it should be clear what people are unsubscribing from. Currently when users click the Unsubscribe they get a vanilla opt-out confirmation button. Even I am not sure what they're opting out from. From the type of email they clicked on, I suppose, which may not be what either of us intended. They should get the same configuration interface that they get when they log into their Profile. (Not that users know to do that, either.)
I agree that further subdivision might be desirable. Eg., from a monthly newsletter vs. other announcements sent manually. Complying this would require some other WA redesign, but could be manually complied with by setting up (and using) Advanced Searches and related data in our Contacts records.
2. Ability for us to provide custom text on the Opt-out page. Every organization has its own particular email practices. Give us the opportunity to clarify ours.
3. Include the user the option of saying why they want out.
4. Make it a two-step process, the second step being the actual opt-out confirmation. Personally, I want opt-outs to be simple, and I hate ones that, after clicking in an email, then ask me to enter what address THEY sent to. (Especially painful for me, because I have many email addresses.) But I don't mind clicking twice instead of once.
Give us opt-out reports. Ideally, tell us WHO opted out. In aggregate it would tell us something about our marketing practices. I do not see it as an invasion of privacy to know this, but even so, I would not contact them further (i.e., no follow-up unless we already have a relationship and there is some specific question). If there were a "why" field in the process, a follow-up wouldn't be called for in the first place.
An opt-out report should at least show which email (if any) triggered the action, the general nature of the opt-outs (member vs. non-member), length of time on the list, source (if we have added that field to our Common Fields), and so on. Anything that might indicate a pattern we should address. The point is, we shouldn't have to go through our entire Emails Log to compile such data (which is impractical and lacks data, so we don't).
Randall (Randy) Rensch
supported this idea
·
-
9 votes
An error occurred while saving the comment Randall (Randy) Rensch
commented
By the way, for some other Wishlist issues, WA has advised fixes that use JavaScript. For any privacy or security issue, as you know, it should not be defeatable just by turning off JavaScript or deleting/revising a cookie. All security and privacy matters should be server-controlled.
An error occurred while saving the comment Randall (Randy) Rensch
commented
This "graying out" capability should be optional, and applied page by page. With some pages it could serve any of several purposes (e.g., remind Members to log in, make non-Members envious, or indicate to Members that the page is available). Examples of this would include "Member list," or "Our last party." But some pages need to be given no publicity at all, for a variety of reasons (e.g., title could reflect badly on non-Members, or gives clues to hackers, or clutters up the menu). Examples might be "Annoying people" (for the record, we have no such page or file!), Financial Reports, or "Reservations tools and reference data for internal use").
An additional thought that is relevant to graying out. For some time, I was complaining that some of our restricted pages were publicly displayed. A fellow member finally pointed out that those pages appear on our menu only when the user is a Member and logged in. (My previous experience was with Apache servers where a folder is restricted and everything under it on the server shares the restriction, and the menus are constructed accordingly. It would be possible to put restricted pages/files on other menus, but they would not be automatically grayed out until login.) Graying out pages would help give a clue, as I said, but we'd have no problem with all our restricted pages being in one Members area that appears on the menu only when logged in. It would be nice if just the top level (e.g. "For Members Only) would appear on the menu, grayed. Currently it appears only after login.
-
86 votes
-
13 votesRandall (Randy) Rensch
shared this idea
·
-
9 votesRandall (Randy) Rensch
shared this idea
·
-
38 votesRandall (Randy) Rensch
supported this idea
·
-
267 votes
Dmitry Smirnov
responded
Even though it is not a direct implementation, I hope this could be helpful:
We just launched integration with Integromat platform, which helps to build automated workflows. We also provide several templates for quick start, and one of them allows to copy google calendar events into WA events. So if you share a google calendar for events submission, then the scenario could copy submitted events into your Wild Apricot account.
You can try this integration by this link https://www.integromat.com/en/integration/2275-copy-google-calendar-into-wild-apricot-events -
3 votes
-
9 votes
An error occurred while saving the comment Randall (Randy) Rensch
commented
I can clone an event, I can clone a Registration form. But can I clone a registration form and move it to another (possibly cloned) event? Apparently not. So EACH of our events cloned from last year (good) have to have their registration forms rebuilt from scratch. Let us "mix and match," please.
Randall (Randy) Rensch
supported this idea
·
-
2 votesRandall (Randy) Rensch
shared this idea
·
-
5 votesRandall (Randy) Rensch
shared this idea
·
-
2 votesRandall (Randy) Rensch
shared this idea
·
-
28 votes
An error occurred while saving the comment Randall (Randy) Rensch
commented
While I'm at it, we could use the abililty for commenters to edit typos in their own comments ... :-)
"a 'swipe' template used only FOR copying from, ..."An error occurred while saving the comment Randall (Randy) Rensch
commented
There are so many typical uses for stock language that I'm surprised it's not already a capability. For example the email header (or text that appears above it), and especially the footer (which can be a LOT of text and links, any part of which might need to be globally changed at any time.) A workaround would be to provide users with HTML code they could paste in, or a "swipe" template used only from copying from, but that requires extra work and user expertise with every email: the need for which the WA model is (or should be) intended to avoid.
Randall (Randy) Rensch
supported this idea
·
-
9 votesRandall (Randy) Rensch
supported this idea
·
-
22 votes
An error occurred while saving the comment Randall (Randy) Rensch
commented
Automatic assembly of an email promoting selected coming events. Each event would include either the "Details" description used on its web page, or a separately entered (probably shorter) version that was entered when the web page was set up. Ideally, the email would have an additional option for automatically choosing content: Up to four events (not necessarily all the sooners) featured at the top of the email, with descriptions, and other events listed below, more as "line items" (not necessarily any photo or long description, just the title, date, link, etc.)
If there can be an optional third section for custom content (e.g., manually entered photos from recent events, or general news or announcement text), that would be nice, too.
It should be possible to create the custom parts of each "omnibus" email ahead of time, so that it will be assembled and sent by the WA system as scheduled.Randall (Randy) Rensch
supported this idea
·
-
28 votes
An error occurred while saving the comment Randall (Randy) Rensch
commented
Need a "Notes" field in each event, for Admins to use. E.g., if we specify an organization address for the Organizer (in order to hid the Organizer's personal address from Announcement recipients), we have no way (within WA) to indicate to each other who the event organizer is!
Randall (Randy) Rensch
supported this idea
·
-
180 votes
Evgeny Zaritovskiy
responded
Merged together several closely related by meaning ideas – so we can properly resolve them all together, in different live scenarios
An error occurred while saving the comment Randall (Randy) Rensch
commented
Do not disclose any personal email address, as sender and/or reply-to, to the recipients of any mass mailing. IOW, allow the organization to specify an address at the organization's domain, which will forward to one or more personal addresses. (If you can't set up the autoforward, it can be done at the domain name Registrar (e.g. GoDaddy), or at Google, etc.) This is a serious personal security/privacy issue!
Randall (Randy) Rensch
supported this idea
·
-
27 votesRandall (Randy) Rensch
supported this idea
·
-
6 votesRandall (Randy) Rensch
shared this idea
·
Yet another reason: When someone joins our mailing list (e.g., a lot of signups at a major event), we sometimes send them a recent email or two, or an omnibus email listing future events ... to get them caught up. It's not just about coming events. We also review past events and have other content, so it's more like a newsletter than just an announcement.
It would be easier to do this by simply sending them to the Recent Emails archive.