Home
Broadly speaking, the flow of this application is to make a voucher that can be used for many things, especially those related to marketing activities. Customers can make vouchers through the landing page. If the customer has made a voucher, the voucher code and instructions will be sent via email. Customers can also make sure that the coupons given are valid.
Administrators can also make vouchers for customers. In addition, the administrator is also responsible for making vouchers as well as registering vouchers that the customer wants to use. Registered vouchers cannot be used again. Vouchers that are overdue (expired) also cannot be used.
Each voucher made has three statuses, among others:
- create, if the voucher was first made.
- expired, if the voucher is past the deadline. Expired checking is done through a loading page voucher list. In addition, when the customer checks the voucher, the checking process is also done whether the voucher has expired or not. If yes, then the voucher status will be updated to expired.
- used, if the voucher has been used and registered by the administrator.
The nature of the voucher is unique, meaning that it cannot be a twin between vouchers with one another. In addition, I also added some additional criteria for the type of voucher such as the validity period (in units of days), the expiration of the voucher and the total vouchers distributed.
The entity of this application consists of two entities, namely customer and administrator.
This application consists of several process lines, including:
In this process, the customer enters their name and e-mail and then checks whether the customer is registered in the database or not. If it has not been registered, then the customer data will be carried out into the database. If the customer is already registered, then it will be checked whether the customer still has a voucher that is still active or not. If the customer still has an active voucher, then the voucher cannot be made, if there is no active voucher, the voucher will be made. After the voucher is made, the voucher code will be sent via the customer's email
This validation process is done to ensure that the voucher is valid and still valid. The trick is the customer goes to the link page for validation which is shared via email.
In the process of making a voucher type, the administrator will make a voucher that will be displayed in the voucher option. Some of the inputs needed include the name of the voucher, the validity period of the voucher (on a daily basis),
Just like the process of making vouchers on the customer side, making vouchers at the backend carried out by the administrator also has the same process as making vouchers by the customer.
When the voucher wants to be used by the customer, the voucher can be registered by the administrator. The registered voucher, the status will change to used, and the voucher cannot be used again
For databases, I use MySQL. The design is as follows
The above view is the result of reverse engineering in MySQL Workbench. To create a database I use the Migration facility from Laravel.
For the landing page display, I use UI / UX from Laravel, while the back-end I use a template from Notika.
The following is the display of the module in the voucher management system.
Some things that can still be developed from this voucher management system application include:
- Delivery of voucher codes via SMS, WhatsAPP and Telegram
- API development
- Integration with other applications such as woocommerce, magento and others