“Can we add a teacher rate?” “Marketing wants Child to say Youth now.” “Seniors go up a dollar on the first of the month.” Each of these sounds like a five-minute edit. In Altru, each one touches a different set of things: programs, web forms, reports, revenue, and sometimes membership discounts. A small rule for who asks, who approves, and who checks the work saves a lot of cleanup later.
Below is how we’d set up that process, organized around the four kinds of requests you’ll actually get.
First, sort the request into one of four types
Most of the trouble comes from treating every price type request the same. They aren’t the same, and they carry very different risk.
1. Change the price of an existing price type
The most common request and usually the safest. The price type stays the same, so your reports keep comparing like with like. The questions are which programs and events the new price applies to, and when. Advance sales already made at the old price should stay at the old price, so pick an effective date and stick to it. If you’re not sure whether changing a price affects orders already sold for future dates in your setup, test it in a sandbox or on a low-stakes program before touching your main admission.
2. Add a new price type
A new audience (teachers, military, a community access rate) usually means a new price type. Before you create one, ask whether an existing type with a discount would do the job. Every new type is one more button for front desk staff, one more line on daily sales reports, and one more thing to remember on every new program. If the answer is still “yes, we need it,” the checklist below covers where it has to be added.
3. Rename a price type
This is the one to slow down on. Price types are shared across programs, so a rename is rarely limited to one place. Depending on how your reports and queries pull the description, past sales may start showing under the new name, which can make year-over-year comparisons confusing (“Why did Child sales drop to zero?”). Before approving a rename, check with whoever owns your attendance and revenue reporting, and confirm in a sandbox how historical transactions display afterward. If you can’t confirm it, treat the rename as a retire-and-add instead.
4. Retire a price type
Deleting is rarely possible or wise once a price type has sales against it. Retiring usually means removing it from programs, web forms, and sales methods going forward while leaving history intact. Decide what replaces it and tell staff what to do when a guest shows up with an old voucher or a pre-printed rate card.
A short intake form
Ask requesters to answer these before anyone opens Altru. A shared form or a simple spreadsheet works fine.
- Which of the four request types is this?
- Which programs, events, or combination tickets does it apply to? “All admission” is not specific enough.
- Which sales channels: front desk, online, group sales, or all three?
- Effective date, and what happens to orders already sold for dates after it.
- Who needs to see it in reporting, and how should it be grouped (for example, does a teacher rate roll up with Adult or stand alone)?
- Who approved the price itself (finance, leadership, the board)?
The checklist after approval
Whoever makes the change should work through every place a price type lives. The exact list depends on your configuration, but in most Altru setups it looks like this:
- Program and event pricing. Add or update the price on every program the request names, including any you set up as templates for future events.
- Sales methods. Make sure the price type is available (or removed) for daily sales, advance sales, group sales, and online as intended. A price type that works at the desk but not online is a common miss.
- Web forms. Check the public ticketing pages. Look at the labels guests will see and the order the options appear in.
- Discounts and membership benefits. If member discounts or promotions apply to specific price types, a new type may not inherit them automatically. Test a member purchase.
- Revenue and GL mapping. Confirm with finance that the new or changed price type posts where they expect before the first batch goes through.
- Reports, queries, and smart fields. Any query that filters on specific price types will quietly miss a new one. Search your saved attendance and revenue queries for hard-coded price type lists.
- Staff materials. Update the desk cheat sheet, rate signage, and any group sales quote templates.
Test, then go live on a calm day
Run one test transaction per sales channel: a desk sale, an online purchase, and a group order if relevant. Check that the receipt or eTicket shows the right label, that a member discount applies when it should, and that the sale appears in your daily sales report under the expected heading. Then refund or void the tests the way you normally would. Schedule the actual change for a low-attendance morning, not the day before a holiday weekend.
Keep a change log
One row per change: date, request type, what changed, programs affected, who requested, who approved, who made it. This sounds like overhead until someone in finance asks in eleven months why Youth revenue appears in March and Child revenue disappears. The log answers that in seconds.
Limit who can make the change
Pricing configuration shouldn’t be editable by every supervisor. Review which Altru security roles can edit price types and program pricing, and keep it to one or two people plus a backup. Everyone else submits through the intake form. That one rule prevents most of the surprises.
Quick answers
Should we create a new price type for a one-day promotion?
Usually not. A discount or promotion on an existing price type keeps reporting cleaner. Save new price types for audiences you’ll sell to long-term.
Can we change a price without affecting tickets already sold?
Generally the price is captured on the order when it’s sold, but confirm how your setup handles future-dated advance sales by testing before you change your main admission program. Blackbaud support can also confirm the behavior for your version.
