How ACHABA Is Proposed to Work

A clear, human system for motorcycle movement in cities like Bauchi

Achaba is proposed as a simple, dependable way for people to move from where they live to where they need to be, especially in places where road access does not reach homes directly.

This section explains, step by step, how Achaba is intended to be experienced by users, and how the system is proposed to respond.

Step 1 of 12

ENTRY: HOW PEOPLE ENCOUNTER ACHABA

Achaba is designed for people who need to move, not people looking to explore an app.

People encounter Achaba through:

  • Community awareness
  • Word of mouth
  • A simple public landing page
  • Field engagement and research activities

From there, people interact with Achaba through:

  • A mobile application
  • Assisted onboarding where necessary

The focus is access, not discovery.

Step 2 of 12

ONBOARDING: FIRST INTERACTION

Users (people) arrive at Achaba for the first time. Very easy. Very welcoming. Very fast. It is designed for rapid access, not exploration.

The user is guided by:

  • Quick login (phone number)
  • Quick terms review
  • Instant access to ride booking (one tap away using Achaba)

The purpose would understand entry steps and start thinking: Price compared, bike pulls ahead.

Step 3 of 12

USER DASHBOARD: PRIMARY CONTROL POINT

Users land on a homescreen that serves as their primary control point.

  • Request a ride
  • Support/help
  • Manage saved places (origin)
  • Profile settings
  • Recent rides

The interface smells calm, simple, not cluttered, with Achaba feel.

Step 4 of 12

REQUESTING A RIDE: USER FLOW

1. Pickup point (auto-detect)

  • GPS sets current location
  • Search location
  • Distance and expected fare

2. Destination (picked)

  • Search location
  • Trip pricing
  • Rider matched (location)

3. Confirmation (trip set of pitch)

  • Confirm booking

The user submits the request without registration or uncertainty.

Step 5 of 12

SYSTEM RESPONSE: MATCHING PROCESS

ACHABA processes the request.

The matching process:

  • Identifies available riders within the relevant area (within X km)
  • Prioritizes nearest riders
  • Notifies available riders (push alert with ride request)
  • Rider accepts (first come basis when fair proximity)

This process is designed to balance proximity, familiarity, and availability.

Step 6 of 12

MATCH CONFIRMATION: USER FEEDBACK

Once a rider accepts.

  • Rider name
  • Rider photo (where available)
  • The rider approach is confirmed!
  • Rider's rating (e.g., 4.7 out of 5)
  • Estimated time of arrival

The user feels informed, safe, confirmed—communication.

Step 7 of 12

PICKUP PHASE: DOORSTEP ORIENTED

The system supports:

  • Live rider location tracking (distance, ETA updates)
  • Direct communication between user and rider (call or message)
  • Pickup confirmation prompt when rider arrives

The rider comes to the user's location (after they sent the journey to the area).

Step 8 of 12

THE RIDE EXPERIENCE

During the ride.

  • Live location tracking
  • Expected arrival updates
  • In-ride support (call, report issue)
  • Route transparency (users see path to destination)

The goal is a predictable, stress-free ride.

Step 9 of 12

COMPLETION AND CLOSURE

At trip end.

  • The rider confirms arrival
  • Payment is processed in the system
  • User rates the trip (1-5 stars)
  • Optional feedback (5 max comments)

The transaction ends clearly and without confusion.

Step 10 of 12

TRUST AND ACCOUNTABILITY STRUCTURE

For riders:

  • ID verification (required)
  • Guarantor system (community based)
  • Rating visibility (users see history)
  • Breach protocol (suspension for misconduct)

For users:

  • Account creation (with verification)
  • Ride history
  • Mutual ratings (riders rate users too)

Trust is maintained through clarity and consequence.

Step 11 of 12

CONTINUOUS LEARNING AND FEEDBACK

Achaba system learns by:

  • Rating and reviews
  • Pickup and completion rates
  • User complaints
  • Rider group check-ins

Learning from the road this way keeps the system rooted in what actually works.

Step 12 of 12

FUTURE EXTENSIONS SEPARATE FROM CORE

Only after core is solid.

  • Errands (pickups)
  • Scheduled rides
  • Vendor partnerships
  • Multi-point trips

These extensions are earned not additions, and depend on platform trust and operational strength.

Closing Summary

ACHABA is not built on assumptions or external blueprints. It's shaped by real feedback from Bauchi riders, real survey responses from users, and respect for the streets where movement already happens.

This is how ACHABA is proposed to work. It's not a promise of perfection, it's a framework designed to evolve with trust, feedback, and operational learning. If it works, it will be because it listens.

Join the Waitlist