The terms used in the system and in our documents — explained in plain language.
Calculating leave entitlement for employees who join partway through the year, based on the months remaining plus the part-month in which they started.
Bringing leave left over from the previous year into the following year, carried over automatically by the system up to the cap set for each leave type.
How late someone may arrive without it counting as a late arrival · in the system this can be set per customer, so when an engineer checks in at a customer site the value for that customer is used instead of the standard value for the shift.
Defining a work cycle of any length (7 days, 14 days and so on) and mapping each day to a shift, with a history of past schedule changes kept.
The sequence of steps a request must pass before it is approved · templates can be set up from the screen yourself, along with conditional rules for which case uses which workflow.
Managing IT service work — in this system it covers service tickets in 3 modes: an internal IT Service Desk, field engineers at customer sites, and Lab Room.
A maintenance agreement — providers sell it as a package of "X call-outs per month", which the system counts in credits.
A service level agreement · in the service request module the system warns once 80% of the deadline has passed and flags anything overdue.
The average room rate per night — room revenue divided by the number of room nights sold, used to see how good a price you are getting for your rooms.
Revenue per available room — unlike ADR it also counts the rooms that went unsold, so it reflects real performance more closely.
The average number of nights per booking — the higher the better, because it lowers cleaning and guest-turnover cost relative to revenue.
How many days in advance customers book before the stay, used to plan promotions and pricing.
The share of rooms occupied against all the rooms available for sale, shown as a percentage.
A mechanism that briefly locks the room type record, counts overlapping bookings and only then writes the booking — rejecting it immediately if the rooms are full, even when several customers book within the same second.
The intermediary that syncs availability and rates between the property system and the OTAs · Naya PMS connects to Channex as a separate module.
The three pieces of data sent out to the OTAs — availability, rates and selling restrictions.
An online room-selling agent such as Agoda, Booking.com or Airbnb — charging roughly 15–20% commission per booking.
The number of guests already included in the room rate; anyone beyond that is charged an extra guest fee per person per night.
A way of working that retrieves the real data first and only then composes an answer from it — rather than letting the AI answer from its own memory. It is the reason the bot does not make things up.
The principle that forces AI answers to reference real data only. Prices and stock are pulled straight from the database, and if nothing is found it does not guess.
What the customer actually wants, read from the message they typed · KuiKeng distinguishes 10 intents, such as browsing products, searching by need and tracking a shipment.
A LINE message format that can show an image, text and buttons in a single card, used to send product cards and room cards.
A set of cards you can swipe through in a single message, used to show a product list or a room catalog.
Shortcut buttons that appear above the text box in LINE so customers can tap instead of typing, for example choosing a quantity or "View order history".
Technology that opens a web page directly inside LINE without leaving for a browser, and signs the user in automatically with their LINE account.
Cash on delivery — the main payment method of the ordering system in KuiKeng, which does not yet support online payment inside the chat.
The official business account on LINE that customers add as a friend and then message · both Naya PMS and KuiKeng run on the LINE OA a business already has.
An architecture that lets many customers use the same system while their data stays completely separate · here the separation starts at the database level, not just filtering inside the application.
A database mechanism that enforces each context seeing only its own rows — a second safety net on top of filtering inside the application.
Assigning permissions by role · the system uses CASL to define permissions as {subject, action} pairs and enforces them on both the web front end and the API.
A record of who did what and when in the system, with a screen for reviewing it afterwards.
An ID that travels with every request as it crosses microservices, so the cause of a problem can be traced accurately even when it passed through several systems.
An authentication token · the system signs it with an asymmetric key (RSA), together with refresh tokens and a revocation mechanism.
The standard password hashing algorithm; the system never stores passwords in readable form.
The digital signature check used to verify that a message genuinely came from LINE and is not a forgery.
A fast service-to-service communication protocol with a clear data contract, which cuts errors at the integration points.
A queue system on Redis that lets heavy jobs — sending email, calculating leave for the whole company, syncing the org chart — run in the background without making users wait.
A feature for matching the columns in an imported file to the fields in the system, and saving the pattern so it can be reused.
Marking a record as deleted without actually removing the data, so it can always be audited later · used when a service ticket is cancelled.
Just ask our team — we explain it in plain language.