Technical Purpose
This document captures the technical requirements behind Bontle as an operational workflow and reporting system. It is based on the architecture and system thinking reflected in the case study and supporting design work.
Technical Objective
The system must support customer booking, workflow control, operational visibility, and reporting from one coherent architecture. The technical design needs to make live workflow data reliable enough for daily operating use as well as management review.
Architecture Overview
The solution was framed around five core layers:
- customer-facing booking interface
- internal admin and consultant portals
- API layer for workflow and service operations
- core backend services
- analytics and reporting outputs
The architecture separates customer interaction, operational workflow logic, and reporting consumption. That separation matters because the same data needs to serve different users without losing operational integrity.
Channel and Interface Layer
Customer Booking Interface
The customer-facing interface must support store selection, service selection, date selection, time-slot selection, and booking confirmation through a mobile-responsive experience.
Internal Portals
Admin and consultant portals must expose workflow-relevant information, not only booking details. Users need visibility into item state, ownership, and follow-up actions.
Future Channels
The design allows for future channel extensions such as WhatsApp or Telegram bots without changing the underlying workflow model.
API Layer Requirements
The API layer must support:
- booking creation and retrieval
- workflow status updates
- user authentication and access control
- reporting or export functions where appropriate
The API layer should act as the controlled interface between the front-end applications and the core backend services.
Core Backend Requirements
The backend must support:
- booking service logic
- user and role management
- analytics and reporting inputs
- notifications or operational alerts
The backend is not only a storage layer. It is where operating rules and workflow controls need to be enforced.
Data and Persistence Requirements
- bookings must remain linked to store, service, date, time, and ownership data
- workflow state changes must be queryable over time
- assignment and reassignment events must be retained
- reporting outputs must reconcile to the underlying workflow records
- the data model must support both operational screens and BI consumption
Workflow and State Logic
- valid state transitions must be enforced on the server side
- role-based permissions must determine who can take which action
- event history must retain timestamps and ownership changes
- retries or duplicate actions must be controlled to avoid corrupting workflow history
Reporting and Analytics Requirements
The system must expose the data needed for:
- throughput reporting
- backlog tracking
- reassignment analysis
- branch-level utilization views
- service output and delay impact reporting
Reporting should not depend on manual spreadsheet reconstruction. The system should make workflow data available in a way that supports executive dashboards and downstream BI use.
Security and Compliance Considerations
- authenticated access is required for internal operational users
- role-based access should limit user actions appropriately
- personal and booking data must be handled in line with POPIA-aligned principles
- exports and reporting should avoid exposing unnecessary sensitive information
Reliability Requirements
- handle repeated actions safely
- preserve workflow history during retries
- support stable queries and pagination for operational views
- ensure operational data remains usable for audit and reporting purposes
Technical Constraints
- the system must stay practical enough for day-to-day operational adoption
- the reporting layer depends on disciplined workflow usage
- future channel expansion should not compromise the integrity of the core workflow
Technical Recommendation
The architecture should continue to prioritise clear separation between interface, API, backend services, and reporting. The strongest technical value in this system is not complexity for its own sake. It is the reliability of the workflow record and the ability to use that record for both operations and decision-making.