General Configuration
Super short version
A master event has one or more Orgs. An org has one or more Registration Groups. A registration group has Packages (and a whole lot of configuration).
Events and Products exist under the Master Event and are selectively packaged up under registration groups as needed/desired.
Fees can be assessed at the Event Option, Event, Product Option, Product, and Package level. Housing and Gifts exist independently of those.
Glossary
Master Event
The root of any major event, sometimes referred to as the umbrella or cycle (though rarely). The master event is created by AlumnIQ for you as needed.
Org
The primary division of registration paths. 90% of our customers route through one org for any given master event. You'd request additional Orgs when logical and financial separation is near-comprehensive. An example is Cornell's Reunion: their undergraduate reunions (of which there are 12-14) exist in one org. Each of the three professional schools have their own orgs as well, allowing for financial and functional isolation of registration data while still sharing a common events pool.
Registration Group
Think of this as a 'track': a set of packages, curated instructions, and common language for a subset (or all of) your attendees. If packages alone don't segment your attendees sufficiently, registration groups can step in to help, but recognize that you're effectively doubling your configuration - and complicating your reporting. Every registrant in a party is required to be part of the same registration group.
Be aware that the more you split up your attendees, the more complicated comprehensive reporting can become. In most cases, showing more packages to a registrant than they'd ever be interested in is not a serious problem - and if you consider all the exceptions that can easily handle, you're probably happier with this more relaxed approach.
Package
A bundle of events and products being offered to a registrant either for convenience and clarity (this is most of the time) or for a fixed rate (this is rarer). Packages are visible to all party members within any given registration group, subject to applicability rules.
Package Group
A package group is a lightweight mechanism for clustering packages together. Consider a scenario where you build multiple packages for a reunion class - you'd have tens of packages visible on one screen. By assigning a handful of related packages to a registration group, then the list gets a lot shorter fairly quickly. If you don't want to use this grouping capability, just leave the field blank.
Event
A thing that people are signing up to attend.
Cap Section
A sub-segment of an event. These are capped slices of event space that are more often than not used as a proxy to limit overall event attendance.
Package Configuration
Every registrant has to select a package, even if that package doesn't convey any direct benefit (a cheaper rate, included events, etc.). Because of that rule, we have to be very thoughtful about how we construct our registration offerings.
At the most flexible end of the spectrum, a single published package with no cost and no benefits, containing for-fee or opt-in events only, will do just fine. This is the typical config for an entirely a la carte weekend.
At the opposite end, consider a reunion or homecoming where you'll bundle a few signature events together along with class-specific programming. Those packages are usually built as a combination of full weekend (for a bundled rate), partial weekend (also typically bundled), and a la carte -- but with featured inclusions.
We don't force you to run everything bundled or everything a la carte - you can mix and match whatever you need. Continuing that theme, you also have the option of creating unpublished packages that are only visible to admins. This is a quick and easy way to prepare the common walk in configurations you're likely to encounter, saving time.
Package Applicability
Historically, our packages required you to assign a demographic (any, adult, youngadult, child 6-12, child 1-5, or infant). That worked generally ok, but many schools found it needlessly and inflexibly granular. Now we have something better.
Packages can now have applicability flags set on them to allow you to target them to any combination of:
primary registrant (always an adult)
adult guest (obviously always an adult as well)
minor/child (with custom age ranges declared by you on a package-by-package basis)
The flexible age ranges make child accommodation a piece of cake. The ability to target a package at an adult guest allows you to easily assign a discounted rate to a spouse, which is a shorthand way to accommodate couples-style pricing.
If you fail to assign applicabilities to a package we'll default them to globally available. We'd rather you be explicit, however.
See more under Package Controls.
Event Fee Applicability (new for 2020)
Event fees can now also be targeted similarly to package applicability.
Any combination of:
primary registrant (always an adult)
adult guest (obviously always an adult as well)
minor/child (with custom age ranges declared by you on a package-by-package basis)
If a given registrant is not eligible for ANY fees attached to a paid event, we'll mark it as "Not Available" on the registration form. This keeps you from having to build any more packages than necessary.
If you fail to assign applicabilities to an event fee we'll default them to globally available. We'd rather you be explicit, however.
Note: we have not added this kind of discriminatory configuration to product fees; file a ticket if you're in a situation that would demand it. We couldn't think of one.
Last updated