Customer Digital Portal — A Case Study

TL;DR

We built a digital customer portal for a logistics business, bringing booking visibility, vessel and fleet tracking, documentation, berth schedules, sustainability reporting, and customer engagement into one secure platform. Using Angular 19, Node.js microservices, MongoDB, SQL, and Azure Functions, the portal shifts customers from fragmented, request-driven communication to a transparent self-service experience. The result: faster access to booking status and documents, reduced manual follow-up across operations teams, automated data synchronisation and reconciliation, and a single digital front door for the entire shipment lifecycle.

Problem Overview

Customers had no consolidated way to check booking status, vessel location, voyage details, or documents — every update required a manual email or phone call to the operations team. Operational data lived across multiple systems with no reconciliation, making it difficult to surface accurate, timely information to customers. Sustainability and emissions reporting was particularly hard to access at the booking, cargo, trade lane, or vessel level, despite growing customer demand for this data.

• Customers relied on manual email and phone communication for booking status, vessel location, voyage details, and berth schedule updates
• Operations teams had no structured way to surface booking changes, delays, laycan and charterer notifications, or documentation updates
• Sustainability and emissions data existed but was not visible at booking, cargo, trade lane, or vessel level for customer reporting
• No secure, unified access management for user onboarding, surveys, announcements, and feedback in one customer experience
• Operational data came from multiple upstream systems requiring reconciliation, synchronisation, and normalisation before it could be shown to customers reliably

Role & Responsibilities

• Role: Full-stack development team
• Responsibilities:
  • Design and build the full customer portal — Angular frontend, Node.js backend services, and Azure Functions automation layer
  • Architect independently deployable services for authentication, booking, master data, vessel tracking, and sustainability
  • Synchronise operational data from multiple upstream systems — voyage, vessel, document, berth schedule, and sustainability feeds
  • Implement secure authentication and API authorisation using Microsoft identity tooling alongside token-based external workflows
  • Build Azure Functions for IMOS data sync, CO2 emission calculations, document reconciliation, notifications, and weekly reporting
  • Develop the documentation hub, ETA/ETB workflows, sustainability dashboards, and customer engagement features
  • Maintain observability and reliability across a distributed repository with separate frontend, API, and serverless deployment units

Project Context

• Industry: Logistics and shipping — booking, vessel operations, and customer service
• Purpose: Replace fragmented, manual customer communication with a unified, secure self-service portal covering booking, vessel, documentation, and sustainability workflows
• Constraints: Data had to be synchronised from multiple upstream systems while staying timely and consistent for customers. Both relational and document-oriented data access patterns needed support through SQL, MongoDB, and service-level repositories. Microsoft identity integration had to coexist with public, token-based customer and partner workflows. Recurring background work — data sync, emissions calculation, reconciliation, notifications, reporting — had to run reliably without manual intervention.

My Approach

We designed the portal as a modular architecture from the outset — a single Angular frontend providing the unified customer experience, backed by focused Node.js services that each own a specific operational domain. Azure Functions were scoped early as the automation layer, handling all event-driven and scheduled work so the core services stayed responsive and free of background processing overhead. This separation meant the business could evolve feature by feature without operational risk to the rest of the platform.

• Domain-driven services: Split backend capability into auth, booking, master data, vessel tracking, and sustainability services — each independently deployable and scalable
• Automation-first: Azure Functions were designed as the dedicated layer for data sync, emissions calculation, reconciliation, and notifications — kept entirely separate from user-facing request paths
• Identity-aware access: Microsoft identity tooling secured internal and customer access, while selected workflows were exposed through public or token-based flows for port-agent and external use cases
• Incremental rollout: Features were delivered modularly — booking monitoring and documentation first, sustainability dashboards and engagement tools layered in afterward

Research & Insights

Key Findings from Discovery

• Customers repeatedly contacted operations teams for the same categories of information — booking status, vessel location, and document copies — making self-service the highest-leverage improvement
• Sustainability and emissions data existed internally but had no customer-facing presentation layer — a clear gap given growing customer demand for ESG reporting
• Operational data inconsistency across upstream systems was a recurring source of customer confusion — synchronisation accuracy mattered as much as the UI itself
• Port agents and external partners needed access to specific workflows (ETA/ETB updates) without full portal accounts — token-based flows were necessary, not optional
• Internal teams wanted configurable notifications and announcements rather than ad hoc emails — a structured engagement layer was a recurring request

Competitive Research

• Most logistics customer portals focused narrowly on booking status — few consolidated booking, vessel tracking, documentation, and sustainability reporting into a single experience
• Sustainability and emissions reporting was rarely customer-facing in comparable platforms, typically confined to internal reporting tools
• Token-based external workflows for port agents and partners were uncommon — most competing systems required full account provisioning for any external access

User Persona

• Name: Karen
• Role: Logistics coordinator at a customer shipping account
• Goals: Check booking and vessel status without emailing operations, download shipment documents quickly, access sustainability data to share with her own management for ESG reporting
• Pain Points: Waiting on email replies for basic status checks, hunting for the right document across multiple channels, no visibility into emissions data for the shipments she manages

Information Architecture

• Booking Monitoring — list, filter, search, export, and inspect booking details, voyage itinerary, cargo information, delays, and operational status
• Vessel & Fleet Visibility — vessel information, tracking views, Q88-style fleet details, and location-related operational insights
• Documentation Hub — download, share, reconcile, and monitor booking-related documents including clean tank certificates, NOR, SOF, ullage reports, and other shipment documents
• ETA & ETB Workflows — berth schedule management, internal ETA/ETB views, voyage itinerary sharing, port-agent updates, OTP/token flows, and discrepancy notifications
• Sustainability Dashboards — emissions, cargo and trade insights, sustainability booking data, SCC reporting, emission factors, fuel lists, and shareable reports
• Customer Engagement — surveys, survey groups, announcements, external notifications, onboarding reports, and feedback capture
• User & Access Management — Microsoft identity-based access, user management, role-aware portal navigation, and secure API access
• Global Search — search across booking ID, cargo type, vessel name, load port, and discharge port to reduce time spent locating information

Visual Language

The portal was built in Angular 19 with Angular Material and Bootstrap — a consistent, professional interface across booking, vessel, documentation, and sustainability sections. Highcharts power the sustainability dashboards and emissions visualisations, giving customers data they can read at a glance rather than raw exports. Google Maps integration supports the vessel tracking and location views. The design prioritises operational clarity — this is a working tool for logistics coordinators and operations teams, not a marketing surface, and the visual language reflects that throughout.

Wireframes & Early Ideas

Early wireframes focused on the booking monitoring list and the documentation hub — the two highest-frequency workflows identified in discovery. The global search experience went through several iterations to support searching across booking ID, cargo type, vessel name, and port simultaneously without overwhelming the interface. The sustainability dashboard required particular care to present emissions and SCC data in a way that was both accurate for internal reporting and presentable enough for customers to share externally for their own ESG purposes.

Designing Solutions

Problem: Customers had no way to check booking, vessel, or document status without contacting operations directly

• Built a booking monitoring module with list, filter, search, export, and detail views covering voyage itinerary, cargo information, delays, and operational status
• Documentation hub allows customers to download, share, and monitor shipment documents — clean tank certificates, NOR, SOF, ullage reports — without requesting copies manually
• Global search lets users find any booking by ID, cargo type, vessel name, load port, or discharge port in seconds rather than navigating through multiple screens

Problem: Sustainability and emissions data had no customer-facing presentation layer

• Built sustainability dashboards covering emissions, cargo and trade insights, sustainability booking data, SCC reporting, emission factors, and fuel lists
• Azure Functions calculate vessel distance and CO2 emissions automatically, keeping sustainability data current without manual data entry
• Reports are shareable directly from the portal, supporting customer ESG reporting and commercial conversations without separate exports or manual compilation

Problem: Port agents and external partners needed access to specific workflows without full portal accounts

• Built OTP and token-based flows for ETA/ETB updates, allowing port agents to submit and view berth schedule information without full account provisioning
• Discrepancy notifications flag mismatches between internal ETA/ETB views and externally submitted updates automatically
• Microsoft identity tooling secures full portal access for customers and internal teams, while token-based flows remain isolated and scoped to specific external use cases

Problem: Operational data from multiple upstream systems was inconsistent and required manual reconciliation

• Azure Functions synchronise IMOS and voyage data on a scheduled basis, keeping customer-facing information timely and consistent across booking, vessel, and document feeds
• Automated reconciliation processes handle documentation and sustainability data, reducing the manual checking previously required between systems
• Weekly onboarding reports and archival processes run automatically, keeping operational data fresh without manual intervention from internal teams

Tech & Implementation

• Frontend: Angular 19, Angular Material, Bootstrap, Highcharts, Google Maps, MSAL Angular — unified customer experience across booking, vessel, documentation, and sustainability
• Backend APIs: Node.js, Express, CommonJS services, Joi validation, route-based controllers and service layers — independently deployable per domain
• Data Access: MongoDB/Mongoose, SQL/Sequelize, Azure Blob Storage, CSV/Excel processing — supporting both relational and document-oriented patterns
• Cloud & Integration: Azure Functions, Azure Storage, Application Insights, SendGrid, Microsoft Graph and identity integrations
• Quality & Operations: Mocha/Jest tests where present, modular packages, independently deployable services, CI/CD-ready structure
• Core services: Auth service (authentication and onboarding), booking service (listings, tracking, ETA/ETB, documentation, exports), master service (ports, contacts, vessels, trade routes), vessel tracking service (location and tracking), sustainability service (emissions, graphs, SCC reporting)

Real-world Features & Highlights

• Booking monitoring → list, filter, search, export, and inspect full booking and voyage detail in one view
• Vessel & fleet visibility → tracking views, Q88-style fleet details, and location insights via Google Maps
• Documentation hub → download, share, and reconcile clean tank certificates, NOR, SOF, ullage reports, and shipment documents
• ETA/ETB workflows → berth schedules, port-agent updates, OTP/token flows, and discrepancy notifications
• Sustainability dashboards → emissions, SCC reporting, emission factors, fuel lists, and shareable customer reports
• Customer engagement → surveys, survey groups, announcements, external notifications, and onboarding reports
• Global search → search across booking ID, cargo type, vessel name, load port, and discharge port
• Microsoft identity access → secure, role-aware portal navigation with token-based external workflows
• Automated background processing → IMOS sync, CO2 emission calculations, document reconciliation, and weekly reports via Azure Functions

Results & Impact

• Improved visibility into booking status, vessel movement, documents, sustainability data, and customer communications — all from a single portal
• Reduced manual effort for recurring updates, document sharing, notifications, data synchronisation, and operational reporting
• Faster customer service response through self-service access and consolidated booking context — fewer requests routed to operations teams
• Better operational control through scheduled automation, reconciliation jobs, and event-driven notification patterns
• A single digital front door created for customer booking, vessel, document, sustainability, and feedback journeys
• Modular architecture allows the client to extend portal capabilities without rebuilding the platform — new features layer onto existing services

Challenges & Learnings

• Multi-system synchronisation — keeping voyage, vessel, document, and sustainability data consistent across multiple upstream systems required careful scheduling and reconciliation logic in the Azure Functions layer
• Mixed data access patterns — supporting both relational (SQL/Sequelize) and document-oriented (MongoDB/Mongoose) data simultaneously required clear service boundaries to avoid data access logic becoming tangled across domains
• Identity vs. token-based access — balancing full Microsoft identity-secured access for customers and internal teams with scoped, token-based flows for external port agents required careful authorisation design to avoid security gaps
• Distributed deployment observability — maintaining visibility across a distributed repository with separate frontend, API, and serverless deployment units required Application Insights integration from early in the build, not retrofitted later
• Sustainability data accuracy — automating CO2 emission calculations required validating Azure Function logic carefully against real shipment data before it became customer-facing and used in ESG reporting

Takeaways

• Self-service reduces operational load measurably: Every booking status or document request handled by the portal instead of a phone call directly frees operations team capacity — the ROI of self-service in logistics is immediate and visible
• Domain-driven services scale better than a monolith: Splitting auth, booking, master data, vessel tracking, and sustainability into independent services meant each could evolve and scale according to its own demand without risking the rest of the platform
• Automation is the backbone of data trust: Customers only trust a self-service portal if the data is current — Azure Functions handling sync, reconciliation, and emissions calculation on schedule is what makes the self-service model credible
• Sustainability reporting is now a customer expectation, not a bonus: Making emissions and SCC data customer-facing was one of the highest-value additions — ESG reporting needs are only growing in logistics
• External access needs its own security model: Token and OTP-based flows for port agents proved that not every external user needs a full account — scoped, purpose-built access patterns are often the right answer for partner workflows

Next Steps

• Advanced analytics and reporting — deeper operational and sustainability insights beyond current dashboards
• Richer notification system — more granular, configurable alerts across booking, vessel, and document events
• Partner integrations — expanding token-based workflows to additional external stakeholders beyond port agents
• Customer-specific reporting — tailored sustainability and operational reports per customer account
• Continued modular expansion — new capabilities layered onto existing services without architectural rework

Client Feedback

"The portal has given our customers a far more transparent, self-service experience — they can track bookings, vessel movement, and documents far more easily from a single place. Internally, our teams benefit from stronger operational visibility, configurable notifications, and automated data refresh workflows. Sustainability data and emissions reporting are now far easier to access and share, which has genuinely helped our customer reporting and commercial conversations. The modular architecture WhizCloud built means we can keep extending the portal without rebuilding the whole platform — that flexibility has been one of the most valuable parts of this project."

— Customer Digital Portal Client

Call to Action

If you are looking to build a customer self-service portal, logistics platform, or operational data consolidation system, contact us at WhizCloud — we'd love to partner with you.