A Digital Platform for Soft Services — From Service Request to Performance Measurement
- Location
- Saudi Arabia
- Period
- 2026
- Status
- In progress
- Role
- Defining the concept, designing the operating model and service cycle, and leading development
Overview
An internal digital initiative within Faculty Members Housing at Imam Mohammad Ibn Saud Islamic University that makes it easier for a resident to request soft services — cleaning services first among them — and to follow them up. It covers the full service cycle: service request, unit identification, scheduling, task assignment, field execution, status updates, request closure, and performance measurement.
Cleaning services and the rest of the soft services within Faculty Members Housing are traditionally managed through scattered channels: a call or a message, then manual assignment, then a verbal closure with no evidence. As a result, the resident has no clear channel to request a service and track it, service quality is estimated rather than measured, and any later review lacks a documented trail. The initiative grew out of this specific operational problem, not from a technology in search of an application.
I present this initiative as what it is: an internal digital platform for improving soft services within Faculty Members Housing at Imam Mohammad Ibn Saud Islamic University, one that makes a resident’s request for a service and its follow-up clearer and easier.
Why it belongs to Faculty Members Housing
The problem it addresses is the problem of soft services within the housing: a cleaning or service request that is not documented, manual assignment, closure without evidence, and quality that is estimated rather than measured. The resident has no clear digital channel through which to submit a request and track its status, and the field teams work without a unified cycle. The platform redesigns this cycle inside the university housing environment.
From assertion to proof
In the traditional model, a request ends when the executor says it is finished. On the platform, it ends only with before-and-after photo evidence. This small change in the closure condition is what makes everything after it — the analytics, the performance indicators, the quality review — meaningful, and gives the resident confidence that the service was actually carried out.
Its operational impact
Digitizing a soft service and actually operating it inside the housing reveals gaps in the operational process that do not appear in theoretical design: where the resident stops, which step gets skipped, and which data is never entered unless the system requires it. These lessons reflect directly on the quality of service delivered to residents and on coordination with the cleaning and execution teams.
Responsibility
My role
- Defining the concept and formulating the full operating model.
- Designing the service cycle, assignment logic, and closure criteria.
- Leading platform development and prioritizing features.
- Linking the platform to quality and performance indicators.
- Actually operating the platform and monitoring its performance in a real environment.
Execution
Project phases
01
Service request and unit identification
The resident opens the app, sees their housing unit, and requests the soft service — such as cleaning — from their unit directly. The request is created linked to the unit and location from its very first moment, so no one needs to re-specify them later.
Role: Designing the request journey and the structure linking the request to the unit.
Outcome: A documented, location-specific request from the moment it is created.
02
Scheduling, assignment, and follow-up
The request is scheduled and assigned to the field execution team, appearing in its daily work list. The request status updates in real time and is followed by the resident and the supervisor at the same time, with support for recurring services and their suspension.
Role: Designing the scheduling logic, assignment, and request states.
Outcome: A single workflow that all parties see with no intermediary.
Handling
Challenges & actions
Each challenge is linked directly to the action taken and its operational impact.
Challenge
Closing requests without evidence of execution quality.
Action
Tying closure to before-and-after photo verification as a condition that cannot be bypassed.
Impact
Turning quality assessment from an impression into an auditable record.
Challenge
Manual assignment slows response and depends on supervisor availability.
Action
Automating assignment according to predefined rules and a daily work list for the executor.
Impact
Faster response without a human intermediary on every request.
Challenge
The absence of unified data prevents performance measurement.
Action
Building performance dashboards that run on the data generated by the workflow itself.
Impact
Actual performance indicators instead of periodic estimates.
Summary
Lessons learned
01
Digitizing an operational service is not moving a paper form to a screen, but redesigning the workflow.
02
The closure condition is what determines data quality later — if closure is easy, the analytics are worthless.
03
Building and operating a digital product reveals gaps in the operational process that do not appear in theoretical design.
