Internal Systems for
OneAirLiving

These 7 systems cover the complete OAL business lifecycle — from the first sales enquiry to ongoing post-sale care. P0 systems are built first as they are operationally critical. P1 and P2 follow in sequence.

Currently many of these roles are worn by the same person. The system is designed around the roles, not headcount — so as OAL grows and roles split into dedicated people, nothing needs to change in the software.

Access is enforced at the API level — not just the frontend. A role that should not see certain data cannot retrieve it even if they know the URL.

Every client engagement follows this pipeline. AE owns the client relationship throughout. OC coordinates field resources for inspections and installations. The pipeline has one branch point at S5 — Closed Cold orders are archived for win/loss reporting, Closed Won orders continue to S6.

Payments are tracked as an array — part payment at S6, final at S9. S5 is a branch, not a linear step. Closed Cold orders are archived with a reason logged, enabling win/loss rate analysis over time.

Once the invoice is issued and AE hands off, the client enters OAL's care vertical. CC manages everything — air quality monitoring, filter replacements, service visits, maintenance, and AMC renewals. This is a recurring, subscription-like relationship that generates ongoing revenue separate from the initial installation sale.

OE, FE, and FC all use the same mobile web app. The role flag on login controls what each person sees and can act on. Location is captured only when an action is submitted — no background GPS, no battery drain, no continuous pings. Every location stamp is tied to a specific work event.

The air quality reading entered at S8 (onboarding) becomes the baseline for that client site. Subsequent readings entered during care visits are compared against this baseline on CC's monitoring dashboard.

Work is sequenced by operational impact. The OMS and WMS are built first as they are the core of the business. Care, monitoring, and reporting tools follow once the sales pipeline is running.

After evaluating both options, neither Google Sheets nor Cloudflare wins outright. Google Sheets is excellent for reporting, formula-driven tools, and human-editable data. Cloudflare KV is built for concurrent high-speed writes and instant reads. The right answer is to use both.

Each option is scored on the criteria that matter most for this system. A 5 means it handles the requirement perfectly. This analysis drove the hybrid architecture decision.

Bagachat is a WhatsApp Business Solution Provider (BSP) that gives OAL a multi-agent inbox, chatbot routing, and webhook API without building raw WhatsApp integration from scratch. It handles two distinct flows — AE-triggered OMS notifications during the sales pipeline, and CC-managed post-sale care conversations.

Meta WhatsApp message charges — India, 2026

A "conversation" in Meta's billing model is a 24-hour window — not a single message. One client enquiry resolved in a day = 1 conversation. Starter plan's 3,000 conversation cap is tight for OAL's volume. Business plan at 15,000 conversations provides comfortable headroom.

OAL currently uses personal Gmail IDs. This works for now but creates problems as the team grows — no centralised admin, no shared drives with proper access control, and AppScript on free Gmail has tighter execution limits. Here are the two options with an honest assessment of each.

Infrastructure costs are low. The dominant spend is WhatsApp (Bagachat + Meta) and Google Workspace. Costs below are shown as Day 1 (launch) and Steady State (6 months in, as the team and client base grow). All figures in INR per month.

Day 1 — at launch

Steady state — 6 months in, as OAL scales

The ₹10,000–15,000 steady-state range assumes: Workspace for all staff, 4 Bagachat agent seats, full Meta message volume, R2 photo storage, and occasional email. Infrastructure (Cloudflare) remains flat at ₹478/mo regardless of scale. WhatsApp and Workspace are the dominant costs — not technology infrastructure.

Four diagrams showing: overall system architecture, the 10-stage OMS pipeline, the field check-in flow, and the post-sale care ticket flow via Bagachat.

Overall system architecture

No frontend app talks to GSheet directly. All writes go through the Cloudflare Worker. GSheet receives data only via the 5-minute background sync — keeping it clean and consistent.

OMS — 10-stage pipeline flow

Blue = AE/PL/OC (internal). Coral = OE + FEs on-site with GPS. Green = coordinator stages. S5 branches into Closed Cold (pipeline ends) or Closed Won (continues to S6).

S2 and S8 are the only OMS stages that capture GPS. S8 also captures the first air quality reading for the client site — this becomes CC's baseline on the monitoring dashboard.

Field check-in flow

One mobile app for OE, FE, and FC. Role flag on login controls what each person sees. GPS is captured only on action submit — no background tracking.

FC gets an additional team map tab showing all assigned FEs' latest check-in locations for the day. No background GPS — every location stamp is tied to a submitted work event.

Post-sale care ticket flow

Everything after S9 is owned by CC. Tickets are either reactive (client complaint) or scheduled (filter replacement cycle, AMC renewal). All client communication goes via WhatsApp through Bagachat.

Scheduled tickets (filter replacement, AMC renewal) are auto-flagged by the system based on configured cycles — CC does not need to remember dates. Reactive tickets are raised manually by CC when a client raises a complaint via WhatsApp or call.