Separate MOS for Packages?

Hey Adriana,

We sell packages through TN Express Web, but do use a unique Mode of Sale.

If we had them in the same MOS, then we would probably just put some custom code in to say for single ticket events, only show certain TR_PRICE_TYPE_CATAGORY's - or something like that?

Beau.

 

www.southbankcentre.co.uk

Follow us on Twitter: @southbankcentre

Ticket Office: 0844 847 9910

Southbank Centre is a Registered Charity No. 298909

______________________________________________________________________

This message (and files transmitted with it) may contain confidential or copyright information. If you receive it in error, please notify the sender and delete it from your computer.

_______________________________________________________________________

Hi Adriana

ACO does CYO packages on the web in the same MOS.

But that's a bit of special coding from Lynch, and some local table work - there's effectively a whole module in there for dealing with CYO (aka NFS) packages neatly. We like it.

If you have a look at LTR_ACO_PRICETYPE_RULES, you'll see that we use a local table which controls which pricetypes can be used in various contexts, including "NFS Pkg" - so our "PAK3" pricetypes are only available in that context, and not in the "Single Tix" context, and other pricetypes are not available in the NFS context. That sort of thing is a fairly straightforward way of getting around the limitation, but obviously, the rest of the site has to be made context-aware if you take that route, so it might involve a moderate amount of webdev work, depending on how the rest of the purchase path works.

K

Hi Adriana,

I'm logged in at the wrong place, but at MTC we do have a different MOS for Subs.  We offer our subscribers Additional single tickets at a discount, so we make these available in the Subs MOS.  However we could equally make standard single tickets availabe in that MOS as well.

You need some web logic to flip the MOS to package, so somthing has to detect that they are already a subscriber (eg they log in and use Ranking to shift MOS), or that they are entering the subs path so the site shifts the MOS.  This makes the process a little more rigid becasue if they abandon the package, you need the MOS to shift back to single lest they continue to try and access subscriber discounts (unless they are already a subscriber via the ranking).  In your case it might not have become that complex yet if you don't intend to offer them cheaper single tickets.

Cheers

Dale.

Adriana,

We use a separate mode of sale for packages (we only sell NFS packages, same as you), but we do allow people to add single tickets (at a discount, we call them "sub add-ons").  The "Web Subscriptions Order" MOS allows price types for fixed show packages, CYO packages, a child package price type and sub add-ons.  But the latter means that to get things to work I have to manually manage which pricetypes can be shown for our SYOS app.  Ultimately this leaves me with the question of whether I shouldn't have just done all this explicit pricetype management outside of Tessitura.  It would certainly require more time and planning in terms of web development, but would also have potentially allowed more flexibility in our offerings.

--Gawain

Thanks all for your responses. There's a lot to think about.

I don't think that switching MOS is an option at all for us. Dale, you're right - there's no need to change pricing for subscribers as we won't have any.

We were hoping to filter by price type name or category but are now looking into creating a local table to manage this (McSwain, we need to talk).

Thanks again,

Adriana