AI and automation for My Trip, a group-travel company

I started in July 2026 on operations’ manual work, including a visa form that staff filled in by hand for every traveller in a group. Within two weeks the company asked me to stay on for the long term, and within eight weeks it approved moving its finance data off spreadsheets into a database.11First work 2026-07-12; management asked to go long-term 2026-07-23 (decision 028); finance-data migration approved the week of 2026-08-31 (decision 125)

What runs today

• Form-fill panels for government portals. One sits on the Tanzania eVisa site and fills each page of the application from the trip’s data; a person still ticks the captcha, reviews, pays and submits. The same pattern runs on Tanzania’s government payment portal. Operations uses both. Panels for Korea’s arrival card and Zanzibar’s inbound insurance are built; no real use of either is recorded yet.
• An itinerary-deck builder. It builds the trip document operations used to make by hand in PowerPoint. Live since September, used by operations; since late October it writes the document from the supplier’s programme.
• The competitor pipeline and the finance search, below.

Still in testing or pilot: a flight monitor, and a WhatsApp assistant for clients that only staff use so far.

Competitor pricing, read up to three times

Competitor pipeline

Fetch7 competitors, Sun and Wed

Extract1 model, up to 3 readings

Votein code2 readings agree → kept

Diffvs. previous run

Mailto me only

A job scheduled for Sunday and Wednesday mornings reads 7 competitors’ sites. One model reads each page up to three times, and a departure counts when two readings agree.22ops-agent market_research: 7 competitors in config/sources.json; pipeline.py EXTRACTION_PASSES = 3, CONSENSUS_MIN = 2, one model for every pass; schedule 0 5 * * 0,3 Asia/Jerusalem; measured in decision 049, 2026-08-08; the report mail is pinned to me; the pin lifts after two consecutive clean runs, 0 of 2 so far (ops-agent HANDOFF, "THE BAR"); the 2026-10-18 run had a false line

The vote exists because of a measurement. On 8 August I extracted the same byte-identical pages four times: one page went from 18 departures to 1, and the model attached another row’s availability cell to a departure and reported it sold out when it was not. With the vote, the worst swing was 6 to 4, and the false sold-out was gone. At the time, the vote tripled the cost of a run.

Two rules sit in the code around the vote. If two readings come back identical, the third is skipped, because it cannot change the result. If readings fail outright, the bar drops to the number that succeeded, so a bad day cannot look like a competitor with nothing for sale.

The result is compared with the previous run, and the report is mailed to me only. It goes to management after their approval and after two consecutive runs in which every line I check against its page holds up. None has passed yet: every run I have read had at least one false line, the latest on 18 October. The pipeline’s results are also on a console open to sales and marketing; only the mail waits.

A database copy under the finance sheet

Finance runs on Google Sheets, and the main file had reached 65% of Google’s 10M-cell limit, most of it empty grid.33Measured 2026-09-03: master finance file at 6,510,438 allocated cells, 65% of the 10M limit; mytrip-db README: a read-only copy, the sheet stays the original; copy lag measured at 41 s I did not move anyone off the sheet. A watcher copies the sheets into Postgres within a minute of a change; the sheet stays the source of truth, staff keep entering data there, and the copy is read-only.

The finance screen’s client search now reads from the copy, straight from the browser with the user’s Google identity, and falls back to the sheet when the copy does not answer. On 7 September the app’s own log put staff searches at 8–12 s that morning and 1.4–2.5 s once search went through the copy. From 15:22 the screen read the copy directly, and searches felt like about half a second, though I logged no timing for that step. To check the fallback I stopped the API in the middle of a session, and the results still came from the sheet.442026-09-07, Apps Script executions log: 7.6–11.2 s across eight morning searches, 8.6–12.5 s from 13:08 to 13:36, 1.4–2.5 s through the copy from 14:06; direct read from 15:22; fallback shown by stopping the API mid-session All of it was measured before the copy moved to the company’s cloud; I have not measured it there.

Around the tools

A shared-context server, so the client’s developer and I, working from two machines, can see what the other changed and who owns which system. A company-wide AI-literacy lecture in August. And a staff page for the tools, which for now shows them to management only.