TEWAKA Operations & Booking Platform

TEWAKA is one of Fiji's most respected transport and destination management companies. Behind the scenes, their team was managing an extraordinary volume of work - up to 170 airport transfers in a single day - using a combination of Excel spreadsheets, paper forms, and three separate booking systems that didn't talk to each other.

Every morning, a coordinator would manually rebuild the day's manifest: pulling bookings from Rezdy, cross-referencing driver rosters in Excel, assigning vehicles by hand, and printing paper checklists for drivers to fill out before each trip. When a flight was delayed - which happens daily in a busy international hub like Nadi Airport -someone had to catch it, recalculate the pickup time, call the driver, and update the manifest. Manually. Every time.

With 60+ vehicles, 40+ drivers, and bookings flowing in from wholesale travel agents, direct customers, and partner operators, the administrative load was immense. None of it was broken in isolation -the team was experienced and capable -but nothing connected to anything else, and the people were doing the connecting by hand.

Pulsebay was brought in to change that. We are building a single, cloud-based platform that pulls bookings live from Rezdy, auto-generates the daily manifest, notifies drivers of their jobs through a mobile app, flags flight delays automatically, captures vehicle checklists digitally, and feeds confirmed bookings directly into MYOB for invoicing. The client retains full ownership of the codebase and hosting -no vendor lock-in, no ongoing SaaS dependency on Pulsebay.

We are currently working through the final phases of delivery, and the response from the TEWAKA team has been immediate. Lala Sowane, Director of Finance and Operations, has described the early experience as transformative -the team are already navigating the platform with confidence and the dispatcher's morning workflow has changed fundamentally. The final phases will bring live flight-delay automation and deeper driver allocation intelligence, but the core is already doing its job.

TEWAKA operates at a scale that exposes the limits of manual coordination very quickly. Sixty-five vehicles ranging from sedans and SUVs to vans and full-size coaches. Forty-plus drivers on rolling fortnightly rosters, each with different license categories that determine which vehicles they can operate. Between 30 and 170 transfers executed every single day, spanning Nadi Airport, Denarau, the Coral Coast zones, Lautoka, and Suva.

Bookings arrived through three systems simultaneously -Rezdy, Tourplan, and a standalone Booking Tool -and none of them communicated with the others. Tourplan was scheduled for full decommission from October 2026, creating a hard migration deadline. The daily manifest was rebuilt from scratch each morning by a human pulling data from the Rezdy export and cross-referencing it against a driver roster maintained in Excel. Vehicle assignments were made by memory and experience, not by any system-level awareness of where vehicles were, how much fuel was in them, or whether they had unresolved defects.

Fleet compliance was another significant gap. Drivers filled out pre-trip and post-trip vehicle checklists on paper forms -capturing odometer readings, fuel levels, defects, and body condition notes. Those forms were then manually re-entered into Simply Fleet, the fleet maintenance tool, "when the R&M team had time." The result was a compliance record that was always running behind reality, with defects potentially going unresolved because the path from driver observation to maintenance action was long and lossy.

Payroll followed the same pattern. Driver hours were tracked on fortnightly Excel rosters, manually separated by rate category -normal, time-and-a-half, double time, overnight, leave -and then re-keyed into a custom payroll system called PAYMAKER. There was no automated link between actual worked hours and what went into payroll.

The most acute operational pain point was flight-linked pickups. A significant proportion of TEWAKA's transfers are arrival pickups from Nadi Airport. When a flight is delayed -a routine occurrence -the pickup time must shift, the driver must be notified, and the manifest must be updated. Under the manual model, this required a coordinator to monitor flight status, make the call, phone or message the driver, and update the spreadsheet. At peak volume, multiple flights could be disrupted simultaneously.

Underpinning all of this was a vendor lock-in concern that shaped the brief from the start. TEWAKA wanted to own what was built -the code, the infrastructure, and the data -from day one.

We approached the platform in deliberate phases, sequencing by business impact rather than technical convenience.

Phase 0 -Discovery & Systems Audit began with on-site immersion in TEWAKA's operations. We reviewed the actual Excel manifests, photographed the paper vehicle checklists, mapped the driver roster structure, and sat with the dispatch coordinator to understand the real decision-making process behind driver and vehicle assignment. We confirmed API availability for all integration targets and locked the Phase 1 scope before a single line of production code was written.

Phase 1 -Bookings & Revenue Layer built the commercial foundation of the platform. A two-way Rezdy API integration provides live booking data -availability reads and booking webhooks -feeding a custom booking front end that replaces both the native Rezdy interface and the legacy Booking Tool for direct consumers and wholesale agency partners. Confirmed bookings trigger automatic invoice creation in MYOB AccountRight, eliminating the manual step between booking and billing. The booking front end was designed to reflect TEWAKA's region-based, group-tiered pricing model -supporting multiple pricing periods that can be pre-loaded and applied automatically based on the transfer date, not the booking date.

Phase 2a -Operations Core is where the platform replaces the daily manual workflow end to end. The dispatch and manifest engine reads every confirmed booking from Rezdy and assembles the day's manifest automatically -no spreadsheet rebuild, no manual data entry. Dispatchers see each unassigned job and the platform surfaces allocation suggestions based on vehicle eligibility, driver license class, shift hours remaining, and projected location at the time of the job. Suggestions are presented for human confirmation rather than automated blindly -this was an explicit design decision aligned with TEWAKA's preference for control.

The driver mobile app delivers each driver's jobs directly to their phone. Before starting a vehicle, the driver completes a digital pre-trip checklist -odometer, fuel level, tyre, lights, door and window checks, accessories, and a body-condition photo -that syncs immediately to the fleet record. Post-trip, the same process captures ending odometer and fuel. Defects flag immediately to the R&M view, removing the lossy paper-to-spreadsheet path entirely. Driver hours accrue automatically from actual shift activity and are available for payroll export in the format PAYMAKER expects.

A live vehicle and driver tracking view gives the operations desk zone-grouped visibility of every active vehicle -status, speed, last GPS ping, and progress through the current job.

Phase 2b -Flight Delay Automation, the current delivery phase, connects to a live flight data feed monitoring all arrivals into Nadi and Nausori airports. When a flight linked to an active pickup is reported delayed, the system recalculates the pickup window, shifts the manifest row, pushes an updated job card to the driver's phone, and logs the event -all without dispatcher intervention. The system handles cascading delays: if a shifted pickup creates a conflict with a driver's next assigned job, the dispatcher is alerted with the affected jobs surfaced for review.

Throughout all phases, the architecture was built with TEWAKA's ownership requirement as a first principle. The platform runs on infrastructure under TEWAKA's own cloud accounts. The codebase is version-controlled in a repository owned by TEWAKA. No ongoing licence fee flows to Pulsebay for the platform to continue operating.

We started not with wireframes but with a day observing TEWAKA's dispatcher at work. The manifest they showed us -rebuilt manually every morning from a Rezdy export, colour-coded by zone, driver columns filled in from memory -was actually impressive. Experienced people had developed a system that worked. Our job wasn't to tell them their process was broken. It was to understand exactly what made it work, and then build something that did the same thing automatically.

The first principle we set was sequencing by revenue rather than technical tidiness. It would have been easier, technically, to start with internal operations -the manifest, the checklists, the roster. But Lala made clear, correctly, that TEWAKA's first priority was serving customers better and converting more bookings. So we built the booking front end and Rezdy integration first, which also meant that when we came to build the manifest engine, the booking data it needed was already flowing cleanly from a live, tested integration rather than a mock.

The pricing model required particular care. TEWAKA runs region-to-region, group-tier pricing across retail, wholesale, service desk, and partner channels -each with different rate structures -and they needed the ability to pre-load an entire year's rate card in advance, with rates applying automatically based on the transfer date of the booking. We designed a period-based pricing system with a tab interface that allows rate periods to be created and managed without touching the booking flow or the underlying price configuration. The period that applies to any booking is resolved at the transfer date, not the booking date -a detail that matters enormously for wholesalers booking months in advance.

The dispatch and allocation problem was the deepest design challenge on the project. With 65 vehicles of all sizes and 40 drivers whose eligibility to drive any given vehicle depends on their license category, the naive approach -show all drivers, show all vehicles, let the dispatcher pair them -produces a very long list that tells you nothing useful. We built a three-pass filter: vehicle eligibility (capacity, status, projected availability), driver eligibility (shift coverage, hours headroom, license class), and cross-match (can this driver reach this vehicle and get to the pickup on time, given their current projected location). The result is a ranked shortlist of two or three viable pairings, each with a visible score breakdown so the dispatcher can see the reasoning and override with confidence.

The driver mobile app was designed for the reality of field use: intermittent connectivity, one hand free, working under time pressure. Every screen has a single primary action. Checklists use large tap targets and a simple OK/Defect toggle. Photos attach with one tap. The job card updates in real time when a flight delay shifts the pickup window -the driver doesn't need to call anyone, and the dispatcher doesn't need to chase them.

Flight delay automation surfaced an important operational nuance. The question isn't just "is this flight late?" -it's "if this flight is late, does the ripple affect any other jobs assigned to this driver or vehicle today?" We built the cascade logic to surface affected downstream jobs alongside the delayed pickup, so the dispatcher has a complete picture rather than a series of disconnected alerts arriving one at a time.

The shift from manual coordination to a connected platform changes the texture of the working day for TEWAKA's operations team in ways that compound quickly. The morning manifest -previously a 45-minute manual rebuild -is ready the moment the first dispatcher opens the platform. Driver assignments that required memory and experience to get right are now supported by a ranked suggestion that accounts for vehicle size, driver hours, license eligibility, and location simultaneously.

Vehicle compliance has moved from a lagging indicator to a live one. Defects that previously might sit on a paper form for a day before reaching the R&M team now flag the moment a driver submits the post-trip check. Wheel tax and service due dates are tracked against live odometer data, not manually maintained spreadsheets.

For drivers, the app replaces a briefing process that required physical presence or a phone call with a job card that's always up to date on their phone. When a flight is delayed, their pickup time shifts and their app updates -they're informed before they'd think to check.

For Lala and the finance team, the link between confirmed bookings and MYOB invoices closes a gap that previously required manual reconciliation. Rate periods mean the correct pricing is applied automatically to every booking, regardless of how far in advance it was made.

The TEWAKA team are already working daily inside the platform with confidence. The final phase of automation -live flight delay handling -is in delivery. What was a network of human-bridged disconnected systems is becoming a single, connected operational picture.

The TEWAKA platform is an example of what it looks like to solve an integration problem rather than a software problem. Every tool TEWAKA was using before this engagement worked in isolation. The pain wasn't bad software -it was the absence of connection between good systems, and the people doing the connecting manually every day.

The decision to phase the build by business impact rather than technical convenience -bookings and revenue first, then operations -is what makes the engagement commercially sensible as well as technically sound. TEWAKA started getting value from Phase 1 before Phase 2 was fully specified. Each phase funds confidence in the next.

The ownership-first architecture reflects a principle Pulsebay holds strongly: a platform should expand a client's capability, not create a new dependency. TEWAKA owns the code, the infrastructure, and the data. If they outgrow Pulsebay, they can take everything with them. That confidence is part of what makes a long-term relationship worth having.

And the allocation logic -the three-pass filter that surfaces ranked driver and vehicle suggestions with visible reasoning -represents the right level of automation for where TEWAKA is. Full auto-dispatch might be right eventually. For now, giving an experienced dispatcher a ranked shortlist they can confirm or override in one click is faster than either full manual assignment or full automation. The human stays in the loop. The tool does the heavy lifting.

Industry: Travel & Destination Management · Location: Fiji · Platform: Web + iOS + Android