The online Calendar allows you to see Performances, past and present, that you may wish to purchase tickets for, have purchased tickets for our are participating in.

The Upcoming Event Calendar can be accessed through a direct link. It can also be added to the main marketing site using iFrames. The My Upcoming Events Calendar allows a quick view of Performances the patron has purchased tickets to. The My Upcoming Activities Calendar displays upcoming activities the patron is scheduled to participate in.

The window lists the status of the cart, the patron's information and the performance details. To refresh the list click the magnifying glass in the upper right corner of the window.

The Status column will indicate if the cart is Active or Expired.

• Tickets in an active cart can never be released - ever. Thats because the patron has them in their shopping cart and, essentially, that would stealing from them. You can, however:
  • help the patron manually check out the shopping cart if they have logged in. You cannot do anything to anonymous shopping carts except let them expire -OR-
  • you can force the cart closed so that the tickets will release when the hold expires
• Expired carts rarely contain held tickets. If they do:
  • check the status of the ticket in a cart - if there was an issue checking the cart out, TM will hold the ticket for up to 96 hours so that you can manage this rare situation. You may need to add that ticket to the patrons cart, or use the Force Carts Closed button to manually release them.
  • In the rare event that a ticket is stuck as held long after the cart has expired, please see the steps below the image for details on released expired holds.

Forcing Carts Closed

If you chose not to manually check out the shopping cart for the patron, and the cart is active, you can force it closed. That means tickets will release in short order.

• Opening the list of shopping carts and searching for the status codes of the ones you want to clean up
• Investigating why they are not complete, if necessary, and fulfilling ticket orders
• Selecting the carts
• Picking 'Force Carts Closed' in the menu
• You will see the image below. Selecting 'Force Close' will change the cart status to cart closed-operator forced it closed. Once carts are properly closed, the patron can be merged with other patrons.

The shopping cart detail window shows what was in the patrons shopping cart and allows you do do some specific things for the patron. Each of the tabs is shown in separate sections.

On the main window, most of the fields deal with the status of the cart and its value. There are two other fields of particular interest:

• Source Tag - which is a convenient way of tying back how people started the shopping cart. This can be used to determine how many people bought from an eblast, or another web site referral -- if the &TMsource=xxx tag is placed on the referring URL.
• User Browser - is the complete string indicating the browser version, platform and application that was talking to the server. You can tell if somebody used a mobile phone, ticket trove, safari and/or a mac, PC or linux machine to talk to the web listener. Refer to the Lookup Use Agent button below.

The Toolbar works as follows:

• Help - Provides help
• Delete - allows a cart with no detail to be deleted
• Print - print some of the lists from the cart
• Customer - if the patron signed in, this will open the patron record for a complete view of the patron. If it is an anonymous cart, you cannot view the patron
• Order - if the patron went through the checkout process, then the cart will be tied to an order. The shopping cart window shows what they wanted to buy - clicking on the 'Order' will open up the order and let you change what they actually bought.
• Checkout - serves two functions, depending on the state of the cart.
  • If the cart is 'Active' (and the patron logged in on the web), clicking on the 'Checkout' button will take the cart away from the web listener and add all the items in the cart to an order. At the end, you will be presented with the payment window so that you can ask the patron to provide a credit card.

    This helps you assist customers who call in to complete their cart, especially if they are having issues with their card not being accepted or they are uncomfortable providing it online for some reason.

  • If the cart is 'complete' and already checked out, it is possible that there are some tickets that are still on hold in the cart. This can happen in very rare cases of high server load. If so, then you can complete the process and convert a ticket on hold in the cart to being sold to the patron at the click of a button.
• Lookup User Agent - this will
  • copy the user agent string to the clipboard automatically for you
  • Open a web site that analyzes what a user string means
  • paste in the user string
  • Click 'Analyze' and that will interpret what the user string is for you (you can see a sample in the image below).

Many organizations wish to track how patrons purchasing online were brought to the online sales website. Generally, they are looking for answers to questions like:

• Did they click the link from the organization's main website?
• Did they follow a link in an email blast?
• Did they click a link from a partnering website?

How to use tmsource

The tmsource reference can be implemented two ways:

1. An internet cookie can be created called 'tmsource'. The text within the cookie can contain up to 100 characters. Using a cookie will prevent the tmsource from appearing in the address bar. The cookie will need to be created by the organizations IT person or web designer.
2. The tmsource option can be added to a link that points to an organizations online sales (See below for details).

Using tmsource is a character based field and does not require access to or changes within the Theatre Manager database. It does not require changes to the Code Tables within Theatre Manager. Do not put an '&' in the tmsource - as this is the parameter separator on URL's.

Adding tmsource to a Link

To create a link containing a source, add &tmsource=XX to any online sales link. Replace XX with the desired text representing the source the patron would have used to access online sales. The value for tmsource can be any value that meets the organization's tracking needs. Some example of possible options are below (prefix them with https://):

• tickets.yourvenue.org/TheatreManager/1/login&event=0&tmsource=MainWebSiteBuyButton
• tickets.yourvenue.org/TheatreManager/1/login&event=0&tmsource=Eblast2014-10-05
• tickets.yourvenue.org/TheatreManager/1/login&event=0&tmsource=TimesUnion
• tickets.yourvenue.org/TheatreManager/1/login&event=0&tmsource=FirstTimeBuyer

How tmsource works with Theatre Manager

Theatre Manager will accept the FIRST tmsource for the shopping cart sent from the patron's IP address. Meaning if the tmsource is set by the sender/referrer site, it will reference that location. If the patron accesses online sales from a location that does not contain a tmsource reference, the source for the cart will remain blank.

If tmsource is not set and the patron uses the back button or a historical cart, it may draw on a prior source value. This could cause a historical cookie to be accessed and create an erroneous source. Chances of that happening are very limited.

Cookies created by Theatre Manager last until the checkout process is complete. If a patron accesses online sales using a link with a tmsource and they complete the check out process, then come back for a second purchase, the tmsource cookie will have already been discarded. The second purchase will have no source at all if the patron does not leave the online sales site or does not access the online sales site using the same method as the first sale. This is the intended action as the patron has not accessed the site for a location the organization is tracking.

tmsource and Theatre Manager

When a source is added to an online cart it can be seen in the Cart Detail window as the Source Tag.

When generating any report that has data tied to shopping carts, the tmsource can be found in the Parameters window as Shopping Cart - Header >> Shop Cart Source. You can use that on most ticketing reports.

Looking at Source in the Shopping Cart List

In the Web Sales Shopping Cart, the tmsource value is located under the Cart Source column.

• talk the patron through the sales process. If you look up the shopping cart, you can use the Web Log tab to see what the patron is doing -or-
• 'take over' the shopping cart on the patrons behalf after instructing them that they will no longer be able to continue.

You might need to do this is the patron: has issues with their credit card or has been marked cash-only for prior non-payment.

To take over a shopping cart for a patron, the following must be true: Taking over a cart: the patron must have logged in to the web site -and- the cart must still be active -OR- Completing a checked out cart: there must be items in the cart that have not been checked out yet -and- the balance < 0 for the order -OR- You cannot take over anonymous carts. Tickets in anonymous carts must expire due to cart timeout before they are accessible.

Clicking on the 'Checkout' button provides a warning that you are about to take over the shopping cart for the patron and gives a chance to cancel the process. Once you continue with the checkout, the cart is marked complete and the patron will not be able to do anything with it.

As per the picture below, if you continue checking the cart out manually, Theatre Manager will

• Create an order
• Attach it to the shopping cart
• Sell all tickets in the cart and attach to the order
• Add all applicable fees, donations and anything else in the cart to the order
• Stop at the normal payment window so that you can finish the order by asking the patron for a credit card

Note: you can also ask the patron if they want any other tickets and purchase them manually as if this were a normal box office order.

• The cart has been checked out and completed successfully with a payment made to it
• There is a balance due to the customer (it looks like an overpayment)
• And there is at least one ticket in the cart that is in the status of Hold expires on xxx and is for this patron

Click the 'Checkout x Ticket' button and you will see a dialog that confirms how many tickets Theatre Manager will attempt to convert from a hold status in this cart to a sold ticket for the patron and order number attached to this shopping cart.

Theatre Manager makes absolutely sure that it can move the ticket from hold to sold for this patron. If there are no issue during the checkout process, then the balance for the order will go to zero and the ticket will change to sold.

This completes the patron cart.

A detail window will open that looks similar to the one below. On the 'email status' tab, any problems with sending that particular email will be shown. If the status tab is blank, it means one of three things:

• the time that the email is scheduled to be sent is not yet upon us.
• the email was sent successfully
• somebody shut down the web listener for some reason.

Note that there an email address drop down. If the patron has more than one email address, you can pick an alternate one to send to; if the issue is with the specific email and not with the email server.

Out of interest, this email shows one common error where the SMTP server is not allowed to relay. This can usually be fixed by entering a user id/password in company preferences or fixing the email server to allow outing emails from the second generation listener machine. Please read for other troubleshooting tips for emails.

TM Server supports auth login, clear-text, md5-cram and communication over TLS/StartTLS or SMTPS. It does not currently support NTLM authentication in Exchange servers. Please use any of the above and TLS/StartTLS for security at this time.

	The most common error is 10060 unable to contact server This means your TM Server machines are unable to talk to your mail server. Thats usually the fault of your mail server or network. Please reset all emails to 'Not Done' and see if they will send. If they don't go eventually, contact your IT people or email provider and find out what the problem is on their end.
	If emails dribble out slowly, it is even more likely to be rate limits at the ISP / Mail Server. Google Mail and Office 365 online accounts are particularly susceptible. Read about Office 365 rate limits - if TM receives limit messages, it will automatically slow down sending emails for you. It may delay password requests etc, so it is better to use a proper mail server.

1. your email server is not working at the current time (reboot it, or call your ISP)
2. the email server is working, but you can't contact it (a rare situation - call your ISP)
3. the customer typed in a goofy email address like bob@yahho.com (this is spelt wrong, but a patron is apt to do that).
4. There is a valid domain for the email address, but the name is wrong. e.g. the patrons name is b smith but they typed bsmth@myemailserver.com or the email address is just plain wrong. (change the email to as best a guess as you have.

Under such circumstances, there is nothing that you can do to make the mail get sent without reviewing the error list and fixing the problem. This is similar to sending from your own personal outlook account ... you can get the same errors from outlook and so, by analogy, you would take the same action.

How to fix email addresses in Theatre Manager?

• Use the menus to go to Patron Sales->Web Sales Module->Pending/Unsent Emails
• Search for all pending emails
• Look at the 'Error' message column. You can double click on the row to see a full transcript of the interaction between Theatre Manager and your email server. Based on the error message (as per the sample below), you may need to:
  1. change the patron's email address to correct it. You can pick one from the drop down, or go to the patron and add a new one or edit an existing one. Make sure it is their primary email address, or if the email address in this list is blank, set it as a primary email address.

     After fixing the patrons email address in the patron record, CHANGE the email address on the individual email and it will be resent using the new address.

  2. if emails do not send because your outgoing email credentials are wrong, then fix them in company preferences (Step 2 above)
  3. if you are getting SMTP: 550 Requested..... messages for most emails, see step 2 above
  4. if you are getting SMTP: 535 Incorrect authentication data yet test emails work, it is probably because you were sending test emails to someone inside the mail server, rather than outside. In that case make sure you email server allows relay from the inside of the network to the world.
• After correcting the problem, change the status of all the emails from Error to Not Done using the tools on the window.
• Alternately, if you can't figure out why a specific email will not sent, change the status to Done
• The web sales listener will pick up all the Not Done messages and try to resend them after a few minutes.

The first place to look is the Manage Pending/Unsent Emails screen to look at the error messages behind the emails that did not get sent. You can look at the error message column, or double click on individual emails to look at the error message tab. The second possibility is that they requested a password reset for an email that does not exist. Refer to finding patrons who request password resets and claim they didn't get an email.

Based on what you find, you may need to take various actions below:

• If their email address is correct, it may indicate a set up problem in the company preferences smtp settings.
• Some emails may be for a future eblast, and since they have not been sent, you just need to wait until they go.
• If there are many, look at an email on a case by case basis and fix the patron's email address if that is what looks to be wrong. you can gain insight from looking at the error message field.
• Use the status button to mark older emails as 'done'.
• Try to send some of them again if they are recent by marking them as 'not done'
• Or a combo of the above.

Each day, you should review the email error log in Theatre Manager that displays any emails in error status. Errors can come from a few sources.

This window shows a log containing a patron's forgotten password behaviour. The entries in the log are curated from:

• Patron transactions showing if the patron was merged, changed their own data online, or had their data changed at the box office. If the box office, for example, changed the email after he password request, it might be an indication that the email address was wrong, and then fixed by box office.
• Patron emails specific to the requesting of passwords and emailing of order confirmations, as well as how long it took TM to send the email and how long it took the patron to read the email. This will tell you how quickly it left TM, and how long the patron took to open it.
• Web logs showing forgotten password requests and issues updating the password including error messages the patron might have received trying to enter their password (like password needs upper case/lower case or a number, etc). If the patron cycles around trying to change the password and never does because of errors, it likely means they are not reading the message on the web page (or the web page/tmError.txt was modified and doesn't show the standard explanatory messages)

What can you see in the logs

The logs are ordered by time stamp. You should be able to see a brief summary of:

• A request for a password email. This would confirm that they did ask for a reset and by the right email address. If the email address did not exist, you would see that message.
• The email sent to the patron. If there is no email, sent, the email did not exist
• If the email exists, attempt to change the password on the email
• If the email does not exist, attempt to create a patron, perhaps using that email address
• Transaction logs indicating that the patron was created, merged, or updated
• and, if the patron finished an order online, you'll see the confirmation email record

What might the forgot password log show

You may see repeats of any of the above behaviour for the patron, so it:

• needs to be carefully read and analyzed to determine what might have prevented them from being successful.
• might indicate when the user last was able to purchase something.
• might indicate somebody who always forgets their email every time
• might indicate somebody who never reads any of their emails, which usually indicates it went to spam
• might indicate if the user was typing as password that does not meet your minimum standards
• .. and more

The log below shows an analysis of what a real user from artsman did to create a set of log entries on a customer database for illustrative purposes.

Where can you access this from

This feature can be accessed from:

• The Web Sales Management menu
• Right-clicking on a patron (with an email) in the patron list window and selecting 'Forgotten Password Log' from the context menu.
• Right-clicking on a patron (with an email) in the Whos In List on the mail list window and selecting 'Forgotten Password Log' from the context menu.
• Clicking the gear icon on an email address in the patron contact card and selecting 'Forgotten Password Log' from the context menu.
• The Web Listener Log if the log entry appears to contain an email

• Open up the web listener log
• Search the log Message field content for Batch Mailer
• You will see one type of message that indicates Sent and Failed each with a count.
  • A Sent count reflects the number of emails that Theatre Manager was able to send successfully
  • A Failed count of other than zero indicates some problem with the email that will need to be diagnosed
  • If everything is successful, then nothing to worry about
• The reason for failed emails is usually in a separate line with an error message. if there are a lot of these, then you can edit/fix some reasons by jumping over to the Manage Pending Emails screen to correct invalid email addresses, etc.

• they typed their email address correctly. (we've found that some people don't type anything).
• the email address exists exactly once in the database. Nothing will be sent if the email address:
  • does not exist, or
  • exists more than once under multiple patrons
  (see below to find these messages)
• the user checked their email program, including spam/trash folders, on all their devices or computers they can use for reading emails
• the email settings in company preferences are valid.
• and the email is not stuck in the pending email list due to some error

Otherwise they will receive nothing

If the patron types an email address that is not in the database, they WILL NOT RECEIVE A WARNING that the email address does not exist. This also occurs if the email exists more than once because it is an error condition. The reason: PCI compliance and privacy laws (like GDPR) require that a system does not divulge any identifying information like names, addresses, or validity of email addresses to anybody who might be trying to determine who or what is in a database. The sample message from web site clearly indicates they will only receive and email if what they type exists. This approach prevents 'bad guys' from scamming emails elsewhere and determine if an account exists on a second web site, where they could obtain products (Like reprinting tickets they could sell to others on the secondary market) should they be able to guess a login id. Error messages can be changed to divulge more information (like email address exists, but password is invalid). This is not recommended if you wish to implement TM in PCI manner for information security.

Finding requests for invalid/nonexistent email addresses

If a patron calls and says that they asked for their password to be reset and did not get an email, you can check to see what email address they used by looking at the web listener logs.

This window is opened from Patron Sales->Web Services->Web Listener Log. For criteria, you may want to use something similar to below:

• Date/Time to narrow things down to a range of days - searching for a month or two is not a problem
• Search within the message text for:
  • email does not exist - use Email Cannot to see those people who did not get an email because the email address does not exist.
  • email exists multiple times - use Email is linked to see those patrons whose email is in the database at least twice and need de-duplicated using the find duplicate email addresses

Looking for only Failed Password Requests

You can see that there are some attempts to request passwords that did not exist. To verify, first ask when the patron requested their password; then using this window, confirm that this is the reason that they received nothing from the system. If there is no message in the log for the email address they described using the day they had the problem, then you will need to check to see if the email is in the queue pending to be sent, or if it was sent.

Verifying all or Specific Password Requests

The following search might also be used to find both requested and failed password requests. it could also be tailored to only search for part of the email address such as 'artman.com' to see all requests from that one domain. The:

• request message will always appear
• failed message will only appear if there is a failure.

General troubleshooting steps are found in the EMV pin pad setup at the end of the web page.

If you activate a pinpad, you should see 6 entries spread out in the web listener log that might help identify where things are in the communication process. These are:

1. the activation of the pin pad
2. a payment validation receipt with the request id - saying that we are going to request the CUSTOMER receipt
3. a payment validation receipt with the SAME request id - saying that we are going to request the MERCHANT receipt
4. a notification that the CUSTOMER RECEPT was retrieved (matching the request ID in step 2)
5. a notification that the MERCHANT RECEPT was retrieved (matching the request ID in step 3)

The above messages are followed by a housekeeping message indicating the number of receipts processed and the number that had an error. Normally, that is 1 processed and 0 in error (unless it is declined for some reason)

If you are looking for problems with one cart, please look at the cart logs to see what the patron has been doing

• a range of dates and
• the contents of the web log as being 3d-

Once you see the message, you can double click on it to see what the message means. Almost all errors are provided to Theatre Manager from the bank such as:

• Do Not honor! (the bank doesn't like the card)
• Declined! (the bank doesn't like the card
• Hold card! (The bank doesn't like the card - it is probably stolen and the want wants to you keep it)

• Card is Blacklisted (means the venue said they didn't want anybody to use this card
• Emergency processing is on (means that the venue turned the merchant processor into emergeny mode and took the cards anyway

Actions that you can take

• Cart - open up the cart to see far more detail about what the patron has been doing
• Patron - open the patron window directly

• for a date range if you know when the ticket was scanned
• the message for the word Scan if you want to see failed scans, successful scans and checkouts
• for the word scan ###### where ###### is the ticket number if you are interested in a particular one
• of whatever combination of criteria you wish.

Note: the logs of scanning are not kept for a long time - only for the retention period set in company preferences.