BPS E-Services: connecting online applications to police service delivery
A product engineering case study in citizen services, operational workflows, and consistent business rules.
Botswana Police Service E-Services brings citizen applications and police administration into a connected platform. It covers public order permits, criminal clearance, livestock clearance, motor vehicle clearance, and firearms services, with shared capabilities for forms, documents, appointments, payments, and notifications.
The central product challenge is coordination. An application submitted online still needs to reach the right station, become actionable work for an officer, follow the correct payment rules, and communicate a meaningful status to the applicant. Each handoff is part of the user experience.
The project combines a Next.js citizen portal and administrative dashboard with Python/FastAPI services. Its most instructive engineering decisions concern how those interfaces and services agree on what happens next.
The users and their needs
The platform serves four connected groups:
| User | Job to be done | What the product must make clear |
|---|---|---|
| Applicants | Apply for a service and follow it through to completion | Required information, payment obligations, appointments, and current status |
| Officers | Review applications and carry out the associated work | Assignment, availability, next actions, and completion state |
| Supervisors | Understand service delivery within their area of responsibility | Pending work, processing times, service targets, and organizational scope |
| Platform administrators | Maintain the people, organizational structure, and configuration behind service delivery | User access, service definitions, forms, notification settings, and audit history |
A useful design has to serve all four. A convenient booking interface is insufficient if the appointment ignores officer availability. A payment setting is insufficient if downstream services interpret it differently. A dashboard is insufficient if its numbers imply a comparison the data cannot support.
The admin platform: operating and configuring the service
The administrative application provides the workspace behind the citizen journey. Its modules span application processing, organizational management, financial operations, and service configuration. This makes the admin experience a substantial part of the product: officers need to act on applications, while administrators need to maintain the rules and structures those actions depend on.
| Admin module | Capabilities represented in the application | Product purpose |
|---|---|---|
| Dashboards | Views for administrators, station officers, district and division leadership, headquarters, and service specialists | Give each role an entry point suited to its responsibilities |
| Users and access management | User records, account creation, identity-verification review, groups, roles, and permissions | Manage who can use the platform and what responsibilities they hold |
| Organizational management | Headquarters, divisions, districts, police stations, police posts, departments, and ranks | Represent the organization used to assign work and define operational scope |
| Services and form builder | Commissioned services, form creation and preview, field validations, profile requirements, appointment settings, and payment configuration | Let administrators maintain supported application requirements through configuration |
| Permits and clearances | Application queues, processing views, and archives for public order, criminal clearance, livestock, motor vehicles, and firearms; specialist Interpol and firearms raffle workflows | Support the distinct review paths behind different public services |
| Emergency operations | Report intake, active and closed incident views, incident details, and officer management | Give emergency work its own operational workspace and lifecycle |
| Appointments and tasks | Booking administration, officer schedules, holiday management, appointment audit and analytics, and personal task views | Connect scheduled visits and application processing to officer work |
| Payments and finance | Transactions, cash collection and shift close-out, refunds, GABS batches, and financial reference settings | Support the administrative work surrounding collection and financial handoff |
| Reports | Application status, service performance, officer workload, organizational, payment, and trend reports | Help supervisors inspect activity and service delivery within their remit |
| Communication and oversight | Messages, knowledge-base content, notification-provider settings, audit logs, and breach records | Support communication, operational guidance, and review of recorded activity |
The product engineering challenge is consistency across this breadth. A station selected in organizational management affects operational scope. A payment requirement configured in the form builder affects the application journey and officer costing. A processing action affects both application status and workload visibility. These relationships make configuration, permissions, and lifecycle behavior central design concerns.
The form builder is a particularly useful example of the balance between flexibility and control. Administrators can express supported requirements without editing each application screen, while the backend still needs to validate submissions and enforce the resulting rules. Configuration becomes part of the product's behavior and must be treated with the same care as code.
The module inventory describes the repository's administrative surfaces. The decisions below examine selected implementations in greater depth; the inventory alone does not establish that every module has passed end-to-end acceptance testing.
Decision 1: make appointments reflect operational capacity
The appointment redesign addressed a documented problem in the earlier implementation: generated weekday slots did not account for officer capabilities, rosters, or public holidays. A scheduling client could also select the first returned slot without checking its availability.
The replacement models availability using working intervals, schedule exceptions, existing appointments, and service-specific capacity rules. It excludes past slots and accounts for weekends and holidays. Where automatic assignment is appropriate, the selection logic chooses a free officer with the lowest recorded load.
An important distinction emerged between services. Livestock and motor vehicle scheduling can support simultaneous bookings when several officers are free. Criminal clearance uses a one-appointment-per-slot rule. The shared engine supports both, preserving the operational difference without duplicating the scheduling logic.
Illustrative example: two available officers can provide two units of capacity for a service that permits parallel appointments. An existing booking consumes capacity. For a service limited to one appointment per slot, adding another available officer does not create another bookable place.
The calculation is isolated from database and network access, making rules such as leave, overlap, and holiday exclusion directly testable. Officers without an explicit roster use standard working hours, an operational fallback that also creates a dependency on keeping roster data accurate.
Product value: appointment availability is connected to the work the organization can perform, with explicit rules for service differences.
Decision 2: treat payment policy as part of the application
The payment-policy design records a mismatch between configuration and behavior: the form builder could describe a free service while downstream components still attempted to charge for it. An empty payment area also left users unable to distinguish a free service from missing information.
The implementation establishes the form's payment configuration as the source of the requirement and stamps that requirement onto the application when it is submitted. Shared policy helpers give backend services a common interpretation of when payment is required.
This makes an important product promise explicit: changing a form's configuration should not retroactively change the payment requirement of an application already in progress. The stored value captures the requirement, rather than promising that every pricing input is frozen.
The interface also distinguishes a confirmed free application from an unavailable policy lookup. Officers see either “No payment required” or “Payment status unavailable,” with guidance to wait before pricing when the rule cannot be confirmed. A temporary lookup failure must not silently become permission to charge or waive payment.
There is a migration tradeoff: older applications without a stored requirement need a fallback and repair path. The implementation supports this, but a missing historical rule cannot always be reconstructed from today's configuration.
Product value: applicants and officers receive a clearer payment state, while distributed services have a consistent rule to enforce.
Decision 3: make application work visible and reporting interpretable
Application processing originally lacked the task records already used for appointments and emergency dispatches. Opening, reviewing, and completing an application could therefore leave an incomplete picture of an officer's workload.
The processing-task design reuses the existing task model. Starting a review creates work in progress; terminal outcomes close the relevant tasks. The handoff model records completion by a different officer, and core task handling updates the application's assigned officer so that the citizen-facing record can reflect who handled it.
This is a practical reuse decision: extend an existing lifecycle instead of creating a parallel workload system. The integration is best-effort so a task-service failure does not block an officer's primary action. The corresponding cost is that workload records can require reconciliation after a failure.
For supervisors, service-performance reporting combines pending work, approval rates, processing time, and service-level targets. Organizational scope limits the area represented by the report.
The data model also exposes a consequential limitation: application counts come from live service statistics, while processing-time and target-compliance calculations use date-filtered application records. These are different views of activity. A defensible report must explain that distinction before users interpret a date selection as applying to every number.
Product value: the platform represents work beyond submission and provides the foundations for supervisors to assess delivery, with identifiable limits on what the metrics mean.
Engineering across the whole journey
The platform uses Next.js, React, and TypeScript for its two web applications; FastAPI and SQLAlchemy for backend services; and PostgreSQL for persistence. Shared Python modules support common behavior such as payment policy and authorization scope. Deployment configuration includes Docker, Nginx, and separate application, data, and reverse-proxy roles.
This architecture allows service-specific workflows alongside shared capabilities. It also creates coordination costs: identifiers, payment requirements, task state, and permissions must remain consistent across boundaries. BPS illustrates why product engineering extends from interface design into domain modeling, integration behavior, and recovery from partial failures.
The repository includes regression tests for scheduling capacity, payment-policy persistence and lookup failures, and authorization boundaries. Those tests provide concrete examples of intended behavior; their presence alone does not establish production reliability or a passing test run.
Outcomes and the next measurement step
The repository demonstrates a broad administrative application alongside the citizen portal, including user and access management, organizational configuration, form building, service processing, financial operations, and reporting. Selected implementations examined here include capacity-aware scheduling, stored payment requirements, explicit free and unknown payment states, processing-task integration, and scoped service-performance reporting.
These are implementation outcomes. This case study does not claim a measured reduction in waiting time, an increase in adoption, or a national rollout. Those conclusions require deployment and operational evidence.
A useful evaluation would measure application completion rate, median and 90th-percentile processing time by service, booking conflicts and no-shows, and payment-related support contacts. Comparing equivalent services and time periods would help distinguish product improvements from changes in demand or staffing.
The project offers a strong discussion of product engineering judgment: translating operational rules into software, carrying those rules across the stack, making uncertainty visible to users, and connecting technical work to outcomes that can be measured.