We would like to find additional ways to simplify different pricing for events. Our use case is that we currently
1.)offer early bird/late pricing for some courses
2.)offer different pricing for provider levels and on-site/remote
As an example of a workflow for early or late pricing, an admin has to manually go into the system on the expiration of early bird pricing support this, an admin has to update the attributes from Store>Products>Attributes. It would be great to be able to schedule price changes, when setting up courses without having to manually update.
While I don’t have solutions for item 2, we’d entertain discussion on ways to simplify or pre-define groupings that could easily be replicated, to lessen the manual entry of these attributes.
I would vote for this but I am out of votes! I agree, luckily we don’t have as many courses in a year, but this is also our struggle.
On point 2 we also have tested numerous ways to set this up, so far we’ve determined setting up two entirely different courses is the best option for reporting (although a lot of work)
Agree, improvements to this area are needed. It is not untypical to offer a early bird rate. We user role based pricing and with a 3 tier pricing structure plus add in the type of learner (employee / non-employee) creates too many pricing fields to complete for building a course and if the course offers early bird rate now you are touching the fields multiple times.
While I agree improvements could be made, we have learned to make certain features work for us.
We use coupon codes to handle EB specials, since coupons can be time limited. We put the info on the registration page and tell them to use the code listed until X date to receive the EB special. This way we don’t have to change the prices on a specific date. You can make coupons pretty specific, tying them to an overall course, or even by assigning alternate SKUs to attribute options and making the coupon only applicable for an attribute or attribute option.
We also use multiple product attributes to be able to offer different pricing. If we want to offer a different price to only UW (and affiliated entities) participants, we do this within the pricing tab because it’s something that is in their profile (role based pricing). Outside of that, then we usually do “honor system” if there is a different price for example, nurses vs doctors - we use product attributes to have two different prices and we don’t police it. If we wanted to do a combo of both - role based pricing (association with UW) and profession based pricing, then we use the “Option prices” tab to adjust how much an option will cost a UW person.
We add additional attributes to change the price for things like live vs virtual, or if there are additional costs they can choose to pay.
We usually make all attributes required, and if they don’t want the attribute (for example they don’t need parking), there is a $0 (No, I do not need parking) option. We had too many people say they didn’t know they needed to choose something when registering ("Oops, I didn’t realize I could pay for parking, can I do that now?) so making all attributes required is helpful.
One of my colleagues asked about scheduling for late fees. This use case seems harder to circumvent. With the feedback on this item, I’ll put in an enhancement request in Jira.
This has been a repeat pain point for years. It would be so helpful to our learner base and encourage more robust enrollment in courses to be able to show the different fee options right up front. At present, the highest price is listed (and then we use attributes and options to adjust by discipline/reg type) and that is discouraging to our Course Directors who are very mindful in their approach to pricing levels by different disciplines. At the course overview and course listing level, it just looks like the most expensive price. Even being able to add a word or a 50-100 instead of only number field would be an improvement.
We have the same issue, as a lot of times Students / Residents are at a greatly reduced fee. When they are looking in the catalog or search API, they only see the highest price and sometimes get turned off, call customer support or may not even come to the course to see their options.
I agree that registration/payment could be improved!
One method we have to keep people from leaving when they see the highest price on the course overview/registration page is to make it so that the price doesn’t show. This way they can see all of the pricing options on the register page. You can do this by adding a line to global CSS code: .page-node-<node#> .group-price.field-group-div, .page-node-<node#> .field.field-name-display-price {display:none;}
Ah yes, true. We use our home page (no fees shown) as a current course view so catalog is not used as much. Would be nice to have the option of removing the cost column from the catalog view! Has anyone done this?
We use the course-catalog-list view which doesn’t include a visible price, but you should be able to remove the price column by adding the following line to your CSS global code: