Hung
Trinh

This is where the emails themselves are built, before anything is sent.

• One template per country and language, so one campaign can run in many markets
• A rich text editor for the email body, plus brand images, subject lines and sender names
• A preview the client can read and approve first

This page decides what goes out today.

• The app suggests a send plan from the campaigns that are ready
• A person has to approve the plan before any email leaves
• A/B tests, and win-back sends for people who stopped opening

We use this to check that the emails really reach the inbox, not the spam folder.

• Every sending domain gets a health score from inbox rate, bounces and complaints
• A domain that turns bad is paused before it hurts the others
• You can tell at a glance which domains are safe to use today

This is where we look at the people we are allowed to email.

• Users are split into nine groups, from active to dormant
• A 30-day view shows if the audience is getting better or worse
• It also shows whether the nightly data sync ran

Used to watch campaigns while they are still running.

• KPI tiles, and how many emails went out each hour
• Rows are flagged when a number looks wrong
• An AI panel writes a short summary of what needs attention now

The finance team bills clients from here.

• Every invoice is tied back to the campaign that earned it
• Revenue reports built from the same records the sales team works in
• Sales and finance read the same numbers, so they do not drift apart

Admins use this page to control who can do what.

• A permission matrix by module and action, edited right in the app
• Extra rules for sensitive fields, such as a client credit limit
• Menus and pages follow the permissions, so people only see what they can use

Drivers keep their cars here before they can post a trip.

• Add, edit or remove a car: name, plate number and number of seats
• Up to six photos per car; the list card shows the first one
• A car used by a coming trip is locked, so the trip data cannot go wrong

A driver offers the seats they do not need on a drive they are making anyway.

• Pick the route, the day, the exact time, the car and the free seats
• A trip has to be posted at least 30 minutes before it leaves
• Two trips that would overlap on the same day are blocked, driving time included

A passenger looks for a trip and asks the driver for a seat.

• Search by route, day and how many people, adults and children
• Say if you bring a pet, big luggage, a baby, an older person, or are pregnant
• Results show the price per person, cheapest first

This is where the driver and the passenger actually agree.

• The driver reads each request and confirms or refuses it
• A seat is only taken when the driver confirms, so waiting requests hold nothing
• Both sides see each other's phone number only after the driver confirms

The price comes from the real driving distance, not from a flat rate. The formula checks six distances.

• You pay for the part you ride, plus extra km only if the driver has to leave the route for you
• The server does all the price work, so a price cannot be faked
• Distances and place search come from xMap, with the map keys on the server, not in the app

A promo code cuts the cash the passenger pays, and the driver still gets the full price.

• XeNow pays the difference into the driver wallet about two hours after the trip ends
• The balance is the sum of a log that only grows, and each trip is paid in once
• If the driver never turns up, the passenger reports it and I hold the money

A separate web app I use to run the service.

• Pages for users, trips, bookings, vehicles, promo codes and disputes
• Admin sign-in has two-factor, with its own setup and verify steps
• The rules live in the database, so the API stays safe even without the app