A scope-by-scope review of the travel operations platform, including functional revisions and the gap to the original three-month plan.
The deepest delivery is in travel execution: lead/customer management, multi-family costing, payment planning, independent lead versions, document review and itinerary sharing. The largest remaining gaps are shared WhatsApp conversations, compliant invoicing, the referral wallet and lifecycle automations.
Nine costing service tables, 17 database-backed report endpoints, formula-aware editing, locked customer funding agreements and review-first document imports show meaningful operational depth. They should be credited without equating them to unrelated unfinished deliverables.
“Built” below means functionality is present in the inspected source. It is not a fresh production acceptance test. No module is declared fully signed off against every original bullet.
| Planned module | Current assessment | Functional revisions* |
|---|---|---|
| 01 · Foundation & InfrastructureWeeks 1–2 | Core built · provider deliverable differs | 4catalogued themes |
| 02 · WhatsApp IntegrationWeeks 3–4 | Capture built · shared messaging remains | 6catalogued themes |
| 03 · CRM Core, Customers & VendorsWeeks 5–6 | Substantial core built · automation gaps | 10catalogued themes |
| 04 · Dashboard & User InterfaceWeek 7 | Live dashboard built · inbox/export gaps | 3catalogued themes |
| 05 · Itinerary Builder & SharingWeeks 8–9 | Core creation/sharing built · library gaps | 7catalogued themes |
| 06 · Costing EngineWeeks 10–11 | Deep operational engine · approval gaps | 11catalogued themes |
| 07 · Invoices, Payments & Family FundingWeek 12 | Funding/payments built · invoicing incomplete | 8catalogued themes |
| 08 · Automation & ReportsWeek 12 · parallel | 17 live reports · lifecycle jobs absent | 2catalogued themes |
*Counts refer to the explicitly numbered themes below. They are not commits, deployments, hours, or a completion percentage.
Each numbered entry describes a meaningful change in what a user or the system can do, calculate, preserve, share or access. Related fixes are grouped into one theme. Purely decorative changes, asset uploads, publication checkpoints and documentation-only edits are not counted.
These are catalogued functional revision themes, reconstructed from the supplied conversation, current source and available Git history—not a claim to know the exact number of implementation rounds. One request can affect multiple modules, so the per-module counts must not be added up as a count of unique change requests. Initial module creation is described under “What is built,” not billed as a revision.
For example, per-cell rounding and rounding costing before markup were discussed earlier. Current code instead applies markup to original costing and rounds the final combined amount once. The report credits the evolution without claiming both rules are active.
Core built · provider deliverable differs
A real multi-workspace application with authentication, API authorization and persistent business data—not just a collection of screens.
Access developed beyond broad roles into default-deny read/write permissions, enforced in both screens and API actions.
Workspace ownership and lead leadership can manage file-specific access; costing-service tabs can have delegated editors without exposing all leads to everyone.
Invitation flows were revised to reject already-associated accounts rather than strand an invitee at signup; invited-user phone validation follows country rules.
Allowed production origins and explicit route policies were tightened so customer links and application requests use controlled access rather than unrestricted endpoints.
d1d6862 · 14 Oct: lead access delegation; 20ea94a and 50edf96 · 15 Oct: auth/team controller changes.
Repository-relative paths are evidence references, not links required to open this document.
artifacts/api-server/src/lib/auth.tsartifacts/api-server/src/lib/workspace-access.tsartifacts/api-server/src/lib/api-route-policy.tsartifacts/api-server/src/controllers/team.controller.tsartifacts/api-server/src/controllers/lead-access.controller.tsCapture built · shared messaging remains
An operational enquiry intake and sales-notification pipeline exists. It is not the shared WhatsApp conversation platform described in the plan.
The intake design moved away from using the CRM lead table to separate chatbot-enquiry storage, keeping CRM records and daily delivery bookkeeping apart.
The capture service can start with its own API key and database connection; sending credentials are required only for delivery work.
The intake expanded to the 14-field chatbot payload, preserving raw content alongside parsed values rather than losing free-text trip details.
Delivery evolved from a daily summary concept into persisted row-level notification tracking; Wavebox acceptance is the agreed completion criterion, not proof of handset receipt.
New-row triggers also recover queued work, with the requested daily 11:00 IST pending-queue pass rather than repeatedly sending completed rows.
The notification formatter omits fields absent from raw_payload instead of inventing a Service type: Not provided line.
43b254c, ff142fd, 9bbd216, 087ac4e, 7805e44 · 10 Oct: capture, queue and delivery evolution.
Repository-relative paths are evidence references, not links required to open this document.
artifacts/api-server/whatsapp-capture/app.tsartifacts/api-server/whatsapp-capture/database.tsartifacts/api-server/whatsapp-capture/delivery-queue.tsartifacts/api-server/whatsapp-capture/delivery-provider.tsartifacts/explorus-crm/src/pages/crm/InboxPage.tsxSubstantial core built · automation gaps
The CRM now handles complex group travel: customers, relationships, families, independent trip scenarios, documents and review-before-save imports.
Customer entry moved to first/last names, with consistent human-label casing while preserving emails, URLs, abbreviations and free-form notes.
Storage stays normalized; optional child phone numbers, country validation and later country-specific visual grouping replaced the earlier no-spaces-everywhere presentation.
Related customer plus relationship became editable across customer/traveller surfaces, including custom relationships and corrected selectable previews.
Departure/arrival editing gained future-year navigation, consistent display, arrival selection and owner-only backdated-entry rules.
Service selections became lead data shared across Add Lead, lead detail and Costing rather than an individual viewer's local choice.
Traveller editing, Family 1 intake and movement across families preserve planned headcounts rather than silently redefining the trip size.
Full lead versions replaced the need to reuse one mutable trip scenario; main-version selection controls aggregate reporting.
Country/city selection, configurable vendor categories and optional vendor notes replaced narrower hardcoded/manual entry behavior.
Multi-person image/PDF extraction now creates reviewable drafts rather than immediately creating customers; approved people can be new or linked customers.
Approved import originals now persist under Raw files, with retry-safe saving and independent reviewed-document copies. Previously discarded originals are not retroactively recoverable.
9a9fb60 and c1b7454 · 14 Oct: dates/services; 0f920e5 · 18 Oct: versions; aa2245d · 21 Oct: bulk import; 85b7b9e · 22 Oct: raw-file/document management.
Repository-relative paths are evidence references, not links required to open this document.
artifacts/api-server/src/controllers/leads.controller.tsartifacts/api-server/src/controllers/customers.controller.tsartifacts/api-server/src/controllers/lead-versions.controller.tsartifacts/api-server/src/lib/lead-versions.tsartifacts/api-server/src/controllers/traveller-import.controller.tsartifacts/api-server/src/controllers/customer-raw-files.controller.tsartifacts/explorus-crm/src/pages/crm/components/BulkTravellerUploadDialog.tsxLive dashboard built · inbox/export gaps
The routed dashboard and pipeline use live application data. A polished screen does not imply that the missing shared inbox is delivered.
Dashboard behavior matured into permission-aware database metrics; main-version filtering and receipt-accounting rules matter to what is counted.
The selected lead subtab is retained through the URL/navigation state rather than resetting every refresh to Travellers.
Settings moved from scattered options to a category sidebar/editor and became the shared source for vendor and costing dropdowns.
d44b624 · 17 Sep: live dashboard enhancement; 263099d and c397472 · 15 Oct: shared dropdown configuration. Tab persistence is also evidenced in current lead navigation code.
Repository-relative paths are evidence references, not links required to open this document.
artifacts/explorus-crm/src/App.tsxartifacts/explorus-crm/src/pages/crm/DashboardPage.tsxartifacts/api-server/src/controllers/dashboard.controller.tsartifacts/explorus-crm/src/pages/crm/PipelinePage.tsxartifacts/explorus-crm/src/pages/crm/LeadDetailPage.tsxartifacts/explorus-crm/src/pages/crm/SettingsPage.tsxCore creation/sharing built · library gaps
Brief and timed itineraries support AI-assisted drafting, saved versions, customer-friendly output and immutable public-share snapshots.
Generation gained structured trip/service and costing context, plus preview/apply behavior, instead of treating every AI draft as authoritative final costing.
Saved history, restore/selection and export targeting developed so users share a selected saved version rather than accidentally exporting unsaved edits.
Separate sharing actions were consolidated into Link, PDF and Text options for brief and timed itineraries.
The text popup became editable for one-off copying without changing the saved itinerary.
Brief text gained travel year, route, guest/pax context and emphasized day headings instead of a less structured generic text export.
A proposed separate route-review step was removed; itinerary-led route inference and supporting costing context feed text, PDF and newly created links.
Public sharing gained revocation and request/access compatibility handling; later source edits do not silently rewrite an already issued snapshot.
82bbf1c and f06e204 · 16 Oct: sharing/access; 132870c · 20 Oct: sharing evolution; 26f688d and 67be3c5 · 21 Oct: route/sharing revisions.
Repository-relative paths are evidence references, not links required to open this document.
artifacts/api-server/src/controllers/briefs.controller.tsartifacts/api-server/src/controllers/itineraries.controller.tsartifacts/api-server/src/controllers/itinerary-shares.controller.tsartifacts/explorus-crm/src/pages/crm/components/ItineraryTab.tsxartifacts/explorus-crm/src/components/itinerary-share/ShareItineraryMenu.tsxDeep operational engine · approval gaps
This is one of the most developed areas: nine service tables, spreadsheet-like formulas, family allocation, currency controls, refund handling and edit history.
Rate cells evolved from numeric-only entry to arithmetic such as 4000/2, displaying 2000 while retaining the expression and formula indicator.
Family formulas accept t in place of total while retaining the established total vocabulary for existing expressions.
Initial weighted allocation stays; editing earlier families recalculates the last family's remainder. Over-allocation shows zero remainder and a mismatch highlight rather than a negative display.
Mismatch highlighting compares displayed/calculated allocations to the row total, not merely whether every family has a saved manual override.
Cmd/Ctrl+Z and redo were added for committed cell edits, then revised for numeric fields, focus movement, queued rapid changes and restoring dependent values.
Copies appear immediately below the source row; drag order is constrained to the row's date group rather than arbitrary cross-date placement.
Cancellation/refund handling became event-based with shared editing behavior and rounding against the original row basis.
Meals, Payment, Status, activity types and transfer modes/types/car types moved to workspace-defined option lists.
Activity Start and transfer departure/arrival/in/out time entry gained time selection; date navigation and backdating restrictions were aligned.
Headers remain visible only within their table, low-screen currency menus open upward, explicit zero is preserved and manual labels use the agreed capitalization.
Per-row notes were added, moved before action controls, then changed from row-expanding textareas to a focused floating editor with bounded previews.
3578adf · 12 Oct: costing updates; 434f61b · 14 Oct: tables; 957c73b, 3e580af, 926168b · 19 Oct: notes; 132870c · 20 Oct: allocation; 4b1887b · 21 Oct: undo/history.
Repository-relative paths are evidence references, not links required to open this document.
artifacts/explorus-crm/src/pages/crm/components/CostingTab.tsxartifacts/api-server/src/controllers/leads-costing.controller.tsartifacts/api-server/src/lib/costing-roe-refresh.tsartifacts/api-server/src/lib/exchange-rates.tsartifacts/api-server/src/controllers/quotation-versions.tsFunding/payments built · invoicing incomplete
Payment planning is considerably richer than a basic receipt tracker. The remaining tax-invoice and referral-wallet work is still material.
The pricing rules were revised so markup follows the underlying source allocation rather than accumulating incorrectly in Bank.
Typing a change into ET transfers that difference from Bank; a later manual Bank edit does not rewrite ET or other sources.
ETO keeps its base costing share, while markup/rounding attributable to ETO is assigned to ETC.
Cell-level and double/base-rounding proposals were superseded. Current logic applies markup to original costing, then rounds the combined selling total up to the next 100 once.
Locking freezes markup input, ROEs, family funding and final selling total; subsequent costing edits change effective profit, not the customer's locked amount.
The locked view was simplified to current costing, locked final, effective markup amount/percent and original-at-lock context; the unlocked layout stays unchanged.
Pending/rejected receipts do not settle balances; older valid receipts remain readable without silently converting historical currencies or payment sources.
Payments and invoice entries can be copied into scenarios without treating copies as additional actual cash; main-version reporting is distinct from simply viewing a scenario.
adc45bb and 814ff1f · 24 Sep: receipt/history changes; a9b884a · 12 Oct: funding independence; 71853f5 and 0f920e5 · 16–18 Oct: pricing/versioning; ad6e5ea and 5d926c8 · 19 Oct: locking/validation.
Repository-relative paths are evidence references, not links required to open this document.
artifacts/explorus-crm/src/lib/payment-summary-pricing.tsartifacts/explorus-crm/src/lib/payment-summary-costing.tsartifacts/api-server/src/controllers/payment-summary-lock.controller.tsartifacts/api-server/src/controllers/leads-payments.controller.tsartifacts/api-server/src/controllers/leads-invoices.controller.tslib/db/src/schema/lead-invoice-entries.tsartifacts/api-server/src/lib/lead-versions.ts17 live reports · lifecycle jobs absent
Reporting breadth is real, but several financial meanings differ from the plan. The five customer/agent reminder automations are not delivered by the enquiry queue.
Financial dashboard/reporting evolved with receipt approval and historical-currency handling, avoiding treating all recorded entries as settled cash.
Scenario versioning introduced designated-main filtering so alternate trip plans do not inflate pipeline/reporting totals.
ad379b1 · 17 Sep: 17 live-data reports; e6f5a8e · 2 Oct: payment/dashboard revisions; 0f920e5 · 18 Oct: version-aware controllers.
Repository-relative paths are evidence references, not links required to open this document.
artifacts/api-server/src/routes/reports.tsartifacts/api-server/src/controllers/reports.controller.tsartifacts/explorus-crm/src/lib/reports-api.tsartifacts/explorus-crm/src/pages/crm/components/reports/ReportFilters.tsxartifacts/api-server/src/lib/lead-versions.tsIllustrative example, not customer data: Costing 3,761 + 22% markup (827.42) = 4,588.42. One upward rounding step produces 4,600, adding 11.58.
If 4,600 is then locked and current costing rises to 4,000, the locked final stays 4,600. Effective markup becomes 600 / 15%. Funding and ROEs do not silently change with that costing edit.
An uploaded family PDF produces reviewable traveller drafts. Approving a person saves or links the customer, preserves that source under Raw files and adds the traveller to Family 1.
Using that raw file for a reviewed passport document creates an independent attachment. The raw original is not automatically treated as a verified identity document.
This is a gap list and sequencing recommendation, not a new schedule, quote or authorization to build. Several tasks can run in parallel after shared data contracts are agreed.
Confirm whether Wavebox replaces WATI contractually or WATI is still required. Implement message/contact storage, inbound webhooks, CRM lead/contact creation, deduplication, assignment, shared inbox, replies/media and the approved template catalog. Acceptance: a real incoming conversation reaches the CRM and can be answered by authorized staff without losing history.
Define validated tax rules; add numbered invoice entities, approved-costing generation, GST/TCS breakdown, payment allocation, branded Excel export and customer sending. Complete costing approval transitions, minimum-margin controls, automatic post-send snapshots and item-level comparisons. Acceptance: trace a quote through approval, invoice, partial payment, refund and outstanding balance.
Add reusable itinerary templates, prebuilt destination/activity content and cross-day activity movement. Agree whether edits should explicitly regenerate costing or follow the plan's automatic recalculation promise. Reconcile source-version locking with today's immutable share snapshots. Acceptance: clone a template for another customer, modify it and prove older customer links remain unchanged.
Add a durable credit/debit ledger, actor/reason audit, partial redemption, expiry policy, approval thresholds and invoice application. Notify customers when credit is issued. Acceptance: a credit can be partially redeemed, reversed and audited without duplicating real money or crossing workspaces.
Birthday, anniversary, passport-expiry, inactivity and overdue-payment workflows need scheduling, timezones, consent/template handling, duplicate-send protection and retry tracking. Acceptance: each runs on the intended date even when there is no user traffic, and does not resend completed work.
Finish pipeline/report CSV exports, true profit and destination-revenue definitions, invoice-ledger outstanding values and message response-time metrics. Verify production OCR/storage, permissions, share links, queue execution and cross-module flows. Resolve the known Brief-to-Costing browser-test gap and capture production acceptance evidence.
Use this as a stakeholder scope review: acknowledge delivered depth, agree the accepted substitutions and changed rules, then turn the remaining workstreams into explicit acceptance criteria. Do not use raw commit counts as a proxy for functional delivery.