info@koortickets.nl
06 2331 2817
Wassenaar, 2244ES, 6
73351709
Jazeker. In het algemeen raden we aan zo weinig mogelijk informatie van de bezoekers te vragen: het invullen van een ellenlange vragenlijst vinden de meeste mensen irritant. Om die reden vraagt KoorTickets in de ticketshop als regel alleen maar om naam en e-mail. Je kunt echter als organisator tot 4 open vragen en 2 meerkeuze vragen hieraan toevoegen. Deze worden opgenomen op het ‘Bevestigen’ scherm wat de klant gepresenteerd krijgt nadat geselecteerd is welke producten besteld worden. Deze vragen kun je definiëren in het scherm ticketshop - klant info, wat te bereiken is via het drop-down menu rechtsboven in beeld (eerst inloggen, natuurlijk), en via een knop onderaan de algemeen of de product invoer pagina’s van je evenement. Je kunt per vraag overigens ook aangeven of de klant verplicht wordt de vraag te beantwoorden voordat de betaalknoppen beschikbaar worden gemaakt.
Op de algemeen pagina van evenement-invoer moet je inderdaad opgeven hoeveel zit-plaatsen en sta-plaatsen er beschikbaar zijn (dit kan overigens 0 zijn). Pas daarna kun je het evenement Opslaan. Op de product-pagina kun je het Max te verkopen veld gewoon leeg laten, maar dat hoeft niet. Hoe en waarom is het best uit te leggen met twee voorbeelden.
Voorbeeld 1: er zijn op locatie 100 zit-plaatsen beschikbaar. Je wilt zit-plaatsen en t-shirts verkopen - van deze laatste heb je 25 laten maken. In dit geval geef je bij algemeen aan dat er 100 zit-plaatsen zijn. Je eerste product noem je bijv. ‘toegangskaart’, en classificeert dit als ‘zit-plaats’. Je hoeft dan op de product pagina geen Max te verkopen meer in te vullen, want bij verkoop van een ‘toegangskaart’ wordt al automatisch het aantal nog-beschikbare-zitplaatsen intern bijgewerkt. Je tweede product noem je bijv ’t-shirt met opdruk’ en classificeert deze als ‘anders’. Hier geef je wel aan dat het Max te verkopen aantal 25 is - als je dat niet doet zal de ticketshop nooit aan kunnen geven dat er al 25 t-shirts verkocht zijn en dat de voorraad dus op is.
Voorbeeld 2: er zijn op locatie 200 zit-plaatsen beschikbaar. Je wilt twee typen toegangskaarten verkopen: één voor de minder vermogende bezoeker, en één voor normaal tarief. Maar je wilt ook dat niet iedereen een ‘goedkoop’ kaartje koopt, dus je wilt dat aantal beperken tot 50. Je kunt dit vorm geven door bij algemeen 200 in te voeren voor het aantal zit-plaatsen, en daarna twee producten in te voeren die je beide als ‘zit-plaats’ classificeert - bijv ‘ticket - goedkoop tarief (max 50)’ en ‘ticket - normaal tarief’. Bij de eerste geef je een Max te verkopen van 50 op. Dit zorgt ervoor dat bij verkoop van beide producten het aantal nog beschikbare zit-plaatsen verminderd wordt en dat je nooit meer dan 50 ‘goedkope kaartjes’ zult verkopen.
Ja, dat kan. Wat niet kan is een product veranderen als daarvan al exemplaren verkocht zijn. Dat zou immers niet fair zijn voor degenen die (de eerdere versie van) dat product gekocht hebben. Wat je in zo’n geval doet is het product verwijderen uit je evenement zodat het uit je ticketshop verdwijnt. Het komt dan als ‘Gestopt’ in je productlijst te staan (bereikbaar vanaf - bijvoorbeeld - je dashboard), en je kunt simpelweg een nieuw product aan je evenement toevoegen (of het gestopte product kopiëren en de kopie aanpassen).
Wat ook niet kan is datum, begintijd en locatie veranderen van een evenement waarvan al producten verkocht zijn. Dat zou immers verwarring zaaien bij degenen die al producten van je evenement hebben gekocht. Je kunt overigens nog wel aanpassingen doen aan andere velden (bijv. Website, Uitvoerende, Titel, etc).
We raden natuurlijk aan een evenement niet meer te veranderen zo gauw er al mensen zijn die iets gekocht hebben, maar dat is uiteindelijk jouw eigen verantwoordelijkheid als organisator.
Goeie vraag. In dit voorbeeld staat de 20 voor de voorraad die er van dit product nog over is. De 10+4 betekent dat er 10 van dit product besteld en betaald zijn, terwijl er 4 wel besteld zijn maar waarvan de betaling nog niet binnen is. De meeste banken garanderen dat bijv. SEPA betalingen binnen 1-3 werkdagen doorgevoerd worden. Als een klant via SEPA betaald heeft kan het dus zijn dat de betaling pas een paar dagen later binnenkomt - of de klant is (als SEPA gebruikt wordt) gewoon vergeten te betalen . In deze periode worden de verkochte producten wel van de voorraad afgetrokken, maar zijn ze nog niet in de Betaald kolom op de productlijst pagina te zien. Mocht de betaling na 3 werkdagen nog niet binnen zijn dan wordt de transactie als ‘verlopen’ gekenmerkt, de gestuurde QR code ge-deactiveerd, en de resterende voorraad bijgesteld. De klant krijgt hiervan bericht, en kan alsnog besluiten te betalen en de ticket te re-activeren (als de op dat moment resterende voorraad dat toestaat).
Waar kan ik zien hoeveel er al verkocht is ?
Dat kan op 3 plaatsen: in de evenementlijst , in de verkoop status lijst en in de productlijst. De eerste twee zijn bereikbaar via het dashboard en de derde vanaf de links die bij elk evenement in de evenementlijst staan (dan zie je alleen de producten van dat evenement) of vanaf het dashboard (dan zie je een lijst van alle producten, en een totaal van alle betalingen voor al je evenementen. In de verkoop status lijst kun je ook zien hoeveel producten er al verkocht zijn en hoeveel er nog over is.
Dat kan middels de op/neer pijltjes in (de 4e kolom van) de productlijst, tenminste als je alleen de producten van één evenement laat zien (te bereiken vanaf de product invoer pagina en via de links die bij elk evenement in de evenementlijst staan. Het kan helaas niet middels de productlijst die alle producten van alle evenementen laat zien (bereikbaar vanaf je dashboard).
Geen probleem. Via de transactielijst kun je de details van je transacties inzien. Via de knop op het dashboard krijg je al je transacties in beeld, en via de link in de op-1-na-rechtse kolom op (elke regel van) de evenementlijst kom je bij de transacties van alleen dat evenement. Als de klant nog weet welke naam gebruikt is, wanneer de aankoop plaats vond, welke producten zijn besteld, of misschien zelfs wat het transactienummer is (begint met RF), kan de transactie gemakkelijk worden teruggevonden. Middels het icon in de tweede kolom van de transactielijst kun je een kopie van de betreffende PDF downloaden en zelf naar de klant opsturen, en door op het icon in de derde kolom te klikken krijgt de klant automatisch het e-ticket nog een keer toegestuurd.
Dat klopt. Regels op deze lijsten kunnen rood, grijs of gewoon zwart zijn.
Allereerst de evenementlijst. Het leek ons een goed idee om, als je een account opent bij KoorTickets, je evenementlijst al vast te vullen met een voorbeeld-evenement. Dit kun je kopiëren (3e kolom van links), maar niet veranderen, en zo’n gefixeerd evenement is daarom rood gekleurd. Om die reden wordt een verlopen evenement ook in rood weergegeven. Een gekopieerd evenement komt in eerste instantie altijd als test-evenement te boek te staan. Evenementen in test-mode (het Ticketing veld op de algemeen invoer pagina van je evenement staat dan op ‘TestTickets’) worden in grijs weergegeven.
Met de productlijst is het vergelijkbaar: als je van een product al exemplaren hebt verkocht in ‘echte’ of in ‘test’ transacties zou je ze niet meer moeten kunnen veranderen, toch? Om die reden worden ze dan ook rood gekleurd. Je kunt zo’n product overigens nog wel verwijderen uit je evenement (dwz, uit je ticketshop), waarmee de Status in kolom 3 op ‘Gestopt’ komt te staan. Grijze regels komen op de productlijst niet voor: als een evenement in test-mode is (Ticketing: TestTickets) wordt dat in de Status kolom op de productlijst als ‘in test’ aangegeven.
Op de transactielijst komt juist de kleur rood niet voor: een transactie is iets van een klant, en kan niet door de organisator veranderd worden. De kleur rood zou dus geen extra informatie toevoegen. De kleur grijs komt wel voor, en heeft de gebruikelijke betekenis: een grijze transactie is een test-transactie, en dit zijn de enige soort transacties die je als organisator kunt verwijderen. Het is trouwens mogelijk dat je echte transacties hebt in een evenement wat je tijdelijk in test-mode geplaatst hebt. Dit soort transacties worden niet in grijs aangegeven (het zijn immers geen test-transacties), maar in de Status kolom wordt dit aangegeven met ‘in test’.
Dat zou inderdaad zomaar kunnen. Als je je evenement in test-mode zet (door bij Ticketing op de algemeen pagina van je evenement-invoer te kiezen voor ‘TestTickets’) dan worden alle transacties die je ooit in test-mode deed meegeteld wat betreft voorraad beheer. De resterende voorraad die je op de productlijst kunt zien zou dan ook anders kunnen zijn, afhankelijk van of je wel of niet ooit een test-transactie hebt uitgevoerd. De transactielijst laat ook test-transacties zien, en telt ze mee, als je evenement in test-mode is, en anders niet. Let wel: de transactielijst bereikbaar vanaf je dashboard laat altijd alle transacties zien, test of ‘live’. Een test-transactie kun je overigens altijd verwijderen als je ze verwarrend vindt.
Ja, dat kan middels het opnemen van een iframe in de html code van jouw website, waarbij je dan niet moet verwijzen naar
koortickets.nl/ticketshop.php?ids=id1;id2
maar naar één van de ‘embed’-versies:
koortickets.nl/ticketshop_embed.php?ids=id1;id2 (zie html-code) of
koortickets.nl/ticketshop_clean_embed.php?ids=id1;id2 (zie html-code)
Zoals gebruikelijk zijn id1 en id2 de IDs van je evenementen zijn die je op wilt nemen (deze kun je vinden op de evenementlijst, bereikbaar vanaf je dashboard, of op de algemeen pagina van je evenement-invoer). De ‘embed-versies’ van de ticketshop heeft geen header, achtergrond of affiche, en integreert daarom op een meer neutrale manier met jouw eigen website.
Let op: het is belangrijk dat je ‘ticketshop_embed.php’ of ‘ticketshop_clean_embed.php’ gebruikt omdat de betaling-functionaliteit niet werkt in een iframe. In tegenstelling tot ticketshop.php openen deze scripts dan ook een nieuw venster als de klant op ‘Bestellen’ klikt.