BIL24 PLATFORM MANAGER APP
DOCUMENTATION IS UNDER CONSTDUCTION
User's Guide
BIL24 PLATFORM MANAGER APP
DOCUMENTATION IS UNDER CONSTDUCTION
User's Guide
APPLICATION MAIN WINDOW
EVENT ORGANIZERS AND AGENTS TAB
TRUSTED AGENTS TAB
FRONTENDS TAB
SUBSCRIPTIONS TAB
NEWS TAB
MEC TAB
WIDGET TAB
PROMOTIONS TAB
REALIZATION PROMOTIONS AND DISCOUNTS IN PROTOCOL
Manager application is used to manage account data of companies and their employees (users) in order to: create frontends and manage them,
control event subscriptions, configure WEB WIDGET, manage mailing of push notifications and to perform various other tasks of tuning and managing ticketing platform resources.
Users with Operator (Network Operator), Event organizer and Agent roles have access to Manager.
Operator is a role of ticketing platform users who are employees of a company exploiting and managing BIL24. Users with this role have maximum rights in the system.
Event Organizer is a role of ticketing platform users who are employees of a company organizing ticket sales on various events. Event Organizer inputs data of events into system,
organizes and manages process of ticket sales via wide Agent network.
Network Operator. In case of platform business model, network is a separate community of platform users with Event Organizer or Agent roles and Customers connected to them. Network Operator holds full rights to manage this community, supervises and controls it.
Network Operator role presents a unique opportunity to create own platform and develop it as an ecosystem for all market participants.
Agent is a role of ticketing platform users who are employees of a ticketing Agent company. Agents sell tickets via their own Frontends (websites, mobile apps, cash desks) and report to Organizer about their sales.
User with Operator role has all tabs available for them in Manager application main window (figure 1).
figure 1
EVENT ORGANIZERS AND AGENTS TAB
These tabs (figures 2-3) display requisites of selected company or Individual Entrepreneur and account data of their employees.
Every Event Organizer and every Agent has their own unique identifier which is displayed in square brackets before their name.
Users with Operator role have adding new companies or individual entrepreneurs via “+” button available to them. Users with Event Organizer or Agent roles don’t have such option, but they can add new employees.
After registration, an employee has to confirm their email and set a password, and this is an activation. If everything is done properly, then employee will have “Activated” checkbox active.
If employee hasn’t used the link and hasn’t set password, then checkbox would be inactive. This checkbox can’t be set manually. Activation is required after each addition of a new employee and after every change of e-mail address.
Activating or deactivating “Work allowed” checkbox allows or forbids user’s actions in BIL24 applications.
figure 2
figure 3
In this tab (figure 4) Event Organizer can define a small number of Trusted Agents, who they trust to receive money off selling tickets to their events. Event Organizer can manually set only Basic agent with internet acquiring who would be used for selling tickets to Organizer’s event via bank cards. Also there is a possibility to create a list of Ticketbox agents, who are allowed by Organizer to collect cash and cashless payments from cash decks and other systems outside of BIL24 system. Every Organizer can have a number of Ticketbox Agents and only one Basic Agent with acquiring. The same Basic Agent can be connected to multiple Event Organizers. Quite often Basic Agent and Event Organizer are the same legal entity.
figure 4
In this tab (figure 5) there is data of selected Agent’s frontends, through which sales are done.
Frontend (FRONTEND) is an interface between customer and ticketing system. Every FRONTEND is owned by an Agent and has a unique identifier FRONTEND ID (FID) and a corresponding token.
These data is used for interaction between frontend and BIL24 central server by Ticketing System Protocol.
Users with Operator or Agent role can add new Frontends using “+” button.
Allowed Frontends:
Android – frontend for selling tickets on Android-based devices.
IOS - frontend for selling tickets on IOS-based devices.
Windows phone - frontend for selling tickets on Windows-based devices.
Browser – frontend for selling tickets through web-browsers.
Mobile browser - frontend for selling tickets through mobile web-browsers.
CASSA – frontend for selling tickets through classic cash decks via cash.
Invitational – frontend for distributing free invitational tickets.
Ticketing system – frontend for interacting with external ticketing systems.
ACS – frontend of Access Control System for checking tickets. Sales through this frontend aren’t allowed.
Face value VAT and Service fee VAT fields – parameters for cash decks, which are displayed in cashier’s check.
In Link field, depending or frontend type, there is presented a link with data (FID and token) necessary to authorize frontend while following a link. In current build of Manager application, link is generated only for Android-type frontends.
For this frontend, link sends to BIL24 Main Mobile App page in GOOGLE PLAY service and contains FID and Agent frontend’s token. While installing app on user’s mobile device, FID and token are input in app’s local storage.
After successful frontend authorization, all tickets sold through this app will appear in Agent’s reports. User who downloaded app from Agent’s link, becomes his client forever. Agent can mail Push notifications to their clients.
Link starts with market:// and opens GOOGLE PLAY MARKET app only on Android-based mobile devices. This provides correct transfer of the data for frontend authorization.
Users with Operator role can mark frontends allowed for an Agent via checks (figure 5).
figure 5
Agents and Event Organizers can’t allow frontends (figure 5.1).
figure 5.1
“Work is allowed” checkbox allows a frontend to work.
In Frontends tab, Operator or Agent can set Agent's Service Fee (ASF) and Frontend’s Service Fee (FSF). In BIL24 ticket platform, service fee is set in percentage of face value of ticket purchased. The following is a list of service fee values:
1. Agent’s Service Fee (ASF). It is set for all Agent’s frontends.
2. Frontend’s Service Fee (FSF). This one is set for a specific frontend (FRONTEND) of an Agent. Replaces Agent’s service fee (p. 1) for this frontend.
3. Minimum service fee for event (MSFE). This one is set by an Event Organizer for a performance in a whole and is present on all sessions of this event. Minimum service fee for event is set in Event Editor app (figure 6).
figure 6
Minimum service fee for event is used in cases when Promoter sets low agent reward, which doesn’t cover acquiring expenses, tax payments and platform cost. For all Agents this is minimum fee they can sell tickets with.
If ASF or FSF are more than MSFE or equal to it, then ASF or FSF is used on electronic frontends, if else, then MSFE is used instead.
On cashier workplace there is used its own Cashier Service Fee (CSF), not connected to system. IF CSF is less than MSFE, then attempts to purchase tickets will result in “Service fee is less than minimum service fee for an event”.
An ability to subscribe events allowed for Agents to different frontends is realized in this tab (figure 7). Access is permitted for users with Agent or Operator roles. By default, each frontend has “All events available” checkbox active. By deactivating it, you can set specific performances for this frontend. This way, every frontend can have its own unique set of events.
figure 7
Event or session check (figure 8) is available for users with Agent or Operator roles.
figure 8
Check is performed for a specific Agent’s Frontend. Report after check has various parameters of events and sessions (figures 9, 10) in it, which influence ability to sell them through this frontend.
figure 9
figure 10
Users with Operator role can mail Ticketing platform news in this tab (figure 11), even in the form of push notifications for mobile devices.
Push notifications are small pop-up windows with text info. They can appear on device’s screen, which has notifications area.
figure 11
Adding news is available for users with Operator role only and can be done by pressing “+” button (figure 12).
figure 12
In “Add news…” window you have to enter news header and select destination address where it would be delivered. It is required to fill in Short title, Description, start of the show (time of news publication) fields.
- “Push” checkbox allows sending news as a push notification to a mobile device.
- “Display is allowed” allows news to be displayed to receivers.
This tab (figure 13) is used for managing Mobile Electronic Cards (MEC). For now, managing MEC is only available for users with Operator role.
figure 13
This tab (figure 14) is available for users with Operator or Agent roles, here you can get links to WEB WIDGET for any city or event.
figure 14
1. Agent selection.
2. Selection of a frontend for widget creation. Widget link transfers frontend’s FID and token.
3. Widget allows selling tickets to a specific event or to all events in specific venue or city. It’s required to choose one of three types:
- for all events available in the city
- for all events available in the venue.
- only for selected event.
4. Language selection.
5. City selection.
6. Selection of event from the list of ones available for this frontend in this city.
7. It’s required to put address of an HTML page where customer will be redirected after successful payment of an order in “URL of successful payment page” field. Successful payment page on bilw.ru is used by default.
8. It’s required to put address of an HTML page where customer will be redirected after unsuccessful payment of an order in “URL of agreement page” field. Agreement page on bilw.ru is used by default.
9. Most of the times widget link is set on “Buy ticket” button. In this field you can set HTML code of this button, so it’ll be added to link code automatically.
10. Text field, where generated link to site-container bilw.ru is located. There is the latest version of widget, which can be used by any Agent without restrictions.
11. Text field containing generated link to widget, which is placed on Agent’s website.
12.Script for displaying widget above page in separate frame. Script has to be placed in page header. An example of using such script: website sochitop10.ru.
13. Button for copying HTML code from text fields to clipboard.
14. Link to WEB WIDGET archive.
15. Users with Operator role can upload ticket templates here.
16. User agreement URL. While purchasing tickets you have to accept user agreement, link to which is received from this field and is put in widget’s bucket. While creating web widget link in performance mode there is automatically included link to user agreement depending on internet acquiring used.
Promo code is a complex of letters, numbers or symbols allowing to purchase goods or services on special offer. Promo codes are one of the tools for stimulating sales.
Promo codes are used for attracting new clients, activating existing clients, rising average check and checking effectiveness of advertising campaigns.
Promotion is a complex of actions targeted to promote events or sessions, which influence potential customers. In BIL24 promotions promo codes are used, to create and change these Promotions tab is used (figure 15).
figure 15
1. Selection of Promoter. Creation of and managing Promotions is allowed for users with Event Organizer or Operator roles.
2. Promotion name. It is displayed to customers together with Promotion description (p. 4), for example, in Android mobile app (figure 16).
figure 16
3. Buttons for adding new Promotion and saving changes in existing Promotion.
4. Promotion description contains info, which Event Organizer wants to tell potential customers (figure 16).
5. Duration of Promotion. Promotion Promo codes are active only during this time.
6. Discount value after applying Promotion promo codes is set in percentage of ticket face value.
7. Restrictions for each promo code: maximum discount and maximum available tickets. One user with confirmed e-mail can use reusable and one-off promo codes only once.
8. Active area of Promotion and its promo codes. Various performances and sessions can be added to active area of Promotion (figure 17).
figure 17
9. Buttons for adding and removing sessions or performances to and from active area of Promotion (p. 8).
8. Button for adding promo codes. Promo codes can be reusable and one-off. In any case one user can use one promo code only for one successful purchase.
This way, reusable “ledovi” promo code with 300 usages available can be used once by 300 users, not 300 times by one user (figure 18). Promo code is set as used only after successful payment of a ticket order.
After cancelling and/unsuccessful payment promo code is sent back to user sometime later. Promo codes are applied automatically to all tickets to sessions and events in the customer’s cart (order).
Promo codes are applied in most profitable way for a customer.
Algorithm for solving an NP-complete combinatorial optimization problem is realized in BIL24 for this cause.
figure 18
One-off promo codes are generated by ticketing platform in set number (figure 19).
figure 19
11. Statistics of promo codes usage.
12. List of promo codes. Used promo codes are highlighted in color.
13. List of promo codes button allows displaying promo codes in text for a convenient distribution of the.
Adding promo codes and applying them by customers are described on following pages:
Using promo codes on Android device.
Purchasing tickets through BIL24 web frontend (WEB WIDGET 2.0).
REALIZATION PROMOTIONS AND DISCOUNTS IN PROTOCOL
In BIL24 test zone there is Aprelski led Promotion for «Lyubimye filmy o glavnom» performance. Promotion works only for sessions during April 16, 18 and 19 of 2025. Promo codes available for promotion:
5kqwd6
zqavy2
c63y4r
a4rzcu
6b5w45
acsftn
dn4p7b
juuu6u
4t4hbd
cwy26q
To receive discount, user (customer) has to add promo code, which will be applied automatically. ADD_PROMO_CODES command in BIL24 protocol (API) is used to add promo codes. Added by user promo codes can be received through GET_PROMO_CODES command, and, for example, they can be displayed in personal area alongside additional promotion info.
Promo codes are applied automatically.
Промокоды применяются автоматически. Algorithm for solving an NP-complete combinatorial optimization problem is used to apply them in most profitable way possible.
Promo code, mobile electronic card and other reasons for a discount have to be shown to customer in a cart. Special fields for this are present in GET_CART command response.
Client ticketing systems selling tickets from BIL24 can set discount value without using promotions or promo codes in CREATE_ORDER_EXT command request.