Skip to main content
Government and non-profit

A request is run by its trace from submission to closure

We implement operating systems for government entities, municipalities, associations, government-owned companies and operations contractors: a request path with its stages and each stage’s time, field inspection with its evidence, a documented approval by the decision owner, a beneficiary register with permissions, and reporting built from data rather than from a file assembled by hand — sized to your entity: a municipality needs requests, permits and inspection; an association needs a beneficiary register, programmes and donations; a government-owned company needs contracts, work orders and indicators; and a national initiative needs stages, outputs and approvals. What they share: what is not recorded with its trace and its time cannot be proven — not to the beneficiary, not to a reviewer, not to the decision owner.

Request an entity assessmentSee the entity types
  • Four entity types, four scopes
  • Not a government entity and not an accredited supplier
  • No automated decision: it stays with the authorised official
  • No claim of compliance with any national platform or standard
  • Beneficiary data is never shared

Direct answers

The questions asked first

Are you an accredited supplier or compliant with digital government platforms?

We claim none of that. We are a systems company: we issue no compliance certificate, accreditation or security clearance, and we assert no conformity with a national standard or integration with a specific platform before inspecting its interface and confirming availability. Any compliance requirement, classification or permit remains the entity’s responsibility and its process with the competent authorities. Anyone telling you the system is “compliant and accredited” without showing you the interface and the test is making a promise they do not own.

Does the system grant eligibility or approve requests automatically?

No. The system records, it does not decide: it gathers the request, its documents and its stages, raises them to whoever holds the authority, and documents the decision, its reason and its time. We build no logic that grants eligibility, rejects an entitlement or ranks beneficiary priority without a declared human approval, because that is a statutory decision belonging to the entity and its responsibility — and putting it in an algorithm transfers responsibility to a program that does not hold it. If automated filtering rules are requested, they are built as published rules approved in writing and their effect is logged.

How do you handle beneficiary and applicant data?

By four rules: the data stays in the entity’s systems and remains its property; we use it for nothing beyond the scope of work; we share it with no third party; and we minimise what is collected to what the procedure genuinely needs. Permissions follow least privilege by role and unit, with an access log for every open or edit and a declared retention period. Data classification, consents and the lawful basis are the entity’s responsibility as the data controller; we implement the controls and issue no certificate and no regulatory opinion.

What usually stops systems projects in government entities?

Three things we see repeatedly, none of them technical: unwritten procedures — a request is run on personal knowledge, so the number of stages and the published duration are unknown; unapproved permissions — who genuinely holds approval is unclear, so a request stalls when one person is away; and non-unified data — names, titles and units in inconsistent forms, making any report hard. That is why we start by writing the procedure, approving the permissions and building a unified reference record, before any promise of a report or a dashboard.

Context

Why this sector is different in the Kingdom

Four operational and regulatory realities impose strict requirements on the system — with no figures and no targets.

Government transformation within Vision 2030

Digitising government services is one of the Vision 2030 axes, with a general direction towards fewer steps and measured beneficiary satisfaction — context that explains the demand for documentation and measurement, while we publish no figures or targets, because they are not ours and we cannot verify them, and we claim no conformity with a national standard.

Context, not a figure

Data classification and permissions

Beneficiary and applicant data is sensitive and subject to a classification the entity sets, so the system is built on least privilege, an access log and a retention period — with classification and consents being the entity’s responsibility rather than ours.

Least privilege and an access log

A decision attributed to its owner

Approval and rejection are statutory decisions of an authorised person, so they must be recorded with their name, time and reason — which is what is asked on any review or beneficiary appeal.

A decision in its owner’s name

A published duration per stage

A service is measured by its published duration, so the system must record each stage’s time so it is known where a request waits — rather than measured by impression or complaint.

The time of each stage

We state the context because it explains the requirements — not to sell with it: we publish no market size, no programme target and no expected improvement percentage, we claim no conformity with a national standard and no integration with a specific platform before inspecting its interface, and we issue no compliance certificate or clearance. The entity is the data controller, the decision owner and the party bearing statutory responsibility; we implement and document the controls.

Entities

Four entity types — and four different scopes

The same sector does not mean the same project. Read your type first, then what fits you — and, plainly, what does not.

Government entity or municipality

Services and permits · field inspection · several units and users

What it suffers from
A request is followed by email or on paper, so which stage it is at and how long it has taken are unknown; inspection is logged in a notebook, and a reviewer requests what is not aggregated anywhere.
What fits it
A request path with its published stages and each stage’s time, permits and documents tied to the request, field inspection with its evidence (photo, location, time), approval in the authorised person’s name, and reports ready for a reviewer from the data itself.

What does not fit you: An advanced beneficiary portal before the procedure is written and permissions are approved, connecting external platforms before inspecting their interfaces, and dashboards before a complete request record exists.

Association or non-profit

Beneficiaries and programmes · donations and expenses · reporting to authorities

What it suffers from
The beneficiary register sits across files, a donation is recorded in a spreadsheet, and spending is linked to the programme by hand, so reporting is late and evidencing a programme’s reach is hard.
What fits it
One beneficiary record with its status and programmes, a donation recorded with its source, spending tied to the programme and the beneficiary, least-privilege permissions protecting beneficiary data, and reporting built from the data.

What does not fit you: An advanced donation portal before the beneficiary register is stable, connecting bank accounts before reconciliation is controlled, and publishing beneficiary data or photos without written consent.

Government-owned company or operations contractor

Contracts and indicators · work orders and maintenance · assets and facilities

What it suffers from
The contract has published indicators, but their measurement is assembled at month end from files, and which work order was late or which asset consumed most is unknown.
What fits it
A contract with its indicators and limits, work orders with proof of execution and response time, an asset and maintenance register with inspection cycles, indicators computed from data rather than a file, and client-ready reporting.

What does not fit you: Relying on a monthly report assembled by hand as the indicator source, managing maintenance outside the system, and connecting facility devices or systems before assets are registered by number.

National initiative or programme

Stages and outputs · committees and approvals · reporting to several parties

What it suffers from
Stages and outputs live in presentations and files, approval is followed by email, decisions are delayed, and which output is stuck and with whom is unknown.
What fits it
An initiative with its stages, outputs and the owner of each output, documented approval per stage, risks and observations on a register, and progress reporting built from data for several parties without duplication.

What does not fit you: Turning the initiative into a dashboard before outputs and their criteria are approved, managing approval by email with no trace, and multi-party reports assembled by hand so their figures conflict.

The bands here are indicative guidance rather than an official classification, and the criterion is the nature of the obligation: a municipality owes a request, a permit and an inspection; an association owes a beneficiary, a programme and a donation; a government-owned company owes a contract, a work order and an indicator; and an initiative owes a stage, an output and an approval. More than one can coexist in an entity, and each has a different starting point.

Symptoms

What usually shows up in entities

Eight recurring symptoms, each with a different root cause — which is why the treatment differs even when the complaint sounds the same.

An unwritten procedure

A request is run on personal knowledge, so the number of stages and the published duration are unknown and execution differs between employees.

Cause: an undocumented procedure

Unapproved approval authority

Who genuinely holds approval is unclear, so a request stalls when someone is away or is approved by someone without authority.

Cause: unapproved permissions

A stage time not recorded

It is known that a request was late, but not at which stage or for how long, so the complaint is treated rather than the cause.

Cause: no stage timing

Inspection with no evidence

An inspection is logged in a notebook or a message with no photo, location or time, making the visit hard to evidence on review or objection.

Cause: undocumented evidence

Broad access to beneficiary data

A user can open records they do not need with no access log — the first thing asked about in any privacy review.

Cause: access without a role

Disbursement with incomplete documents

The amount is paid and the document completed later or not at all, so the observation appears at review after correction is too late.

Cause: an incomplete document

A report assembled by hand every time

A periodic report is requested and assembled from several files, arriving late, carrying a copying error and conflicting between two reports.

Cause: a report without a source

An output with no declared owner

The output is named in a presentation but who follows it and its date are unknown, so it slips unnoticed until the stage ends.

Cause: no output owner

Components

What we implement in the entity

Eight components built in order according to your type; we do not implement all of them for an entity that does not need them all.

The written procedure and its published stages

Every service or procedure with its stages, published duration and required documents — the base everything else is built on.

The base

The request record and its documents

One request with one record: its status, stage, documents and attachments, and who handled it and when, with no searching through email.

A request with its trace

Permissions, approval and access trails

Who enters, who approves and who views, a record documenting the decision with its owner, time and reason, and an access log for every open or edit.

A decision in its owner’s name

Field inspection and execution with evidence

A field app that works offline: checklists, photos, location and time, and proof of visit tied to the request or order.

A documented visit

Beneficiary and programme register

A beneficiary with their status and programmes, a donation with its source, and spending tied to the programme — under permissions that protect beneficiary data and minimise collection.

Minimal data

Contracts, work orders and indicators

A contract with its limits and indicators, work orders with response time and proof, and indicators computed from data rather than a monthly file.

A computed indicator

Initiative stages, outputs and owners

A stage with its outputs, criteria, each output’s owner and date, documented approval per stage, and a risk and observation register.

An output with its owner

Reporting and the access log

Reporting built from data for several parties without duplication: request status and durations, inspection, disbursement and stage progress — with no claim about outcomes.

A decision, not an archive

Method

The method: from writing the procedure to operation

Eight stages, each with a published output, starting by writing the procedure and approving permissions rather than with configuration — because a system on an unwritten procedure freezes the disagreement rather than resolving it.

  1. 01

    Assessment and entity type

    A visit covering the service, the procedure and field units, establishing the real entity type, what runs on email or paper today, and where the largest operational risk sits.

    Output: an assessment naming your type
  2. 02

    Writing the procedure and approving permissions

    Documenting each service’s stages, duration and documents, and approving in writing who enters and who approves — before any configuration, because a system on an unwritten procedure freezes disagreement.

    Output: an approved procedure and permissions
  3. 03

    Unifying master data

    Unifying unit names, titles, categories and services and cleaning duplicates — because every report after it rests on this classification.

    Output: a unified reference record
  4. 04

    Configuration and testing

    Configuring the request, stages, approval and inspection, and running a full cycle on anonymised data: submission, stage, approval, inspection, closure.

    Output: one complete tested cycle
  5. 05

    Phased go-live

    Going live on one service or unit first, then expanding — not switching all services in one day nor during a peak season.

    Output: one service running, then expansion
  6. 06

    Training and guides

    Training each role on its own process: reception, the field team, the approver and finance — with illustrated guides left with you.

    Output: a guide per role
  7. 07

    Integration and reconciliation

    Connecting what can genuinely be connected after inspecting the interface, reconciling disbursement and approvals with accounting, and closing a first documented period with its differences.

    Output: a documented close with its differences
  8. 08

    Periodic improvement

    A periodic review: where a request waits longest, which stage is late, which output has no owner, and which report nobody uses so it can be dropped.

    Output: a periodic improvement report

The durations shown are planning ranges to help you build your schedule, not contractual commitments: the actual duration depends on how fast the procedure and permissions are approved and on the readiness of your data, and can be affected by service seasons or reporting dates.

Measurement

What we measure in a government project

Indicators read from the operation itself, not promises about percentages or outcomes.

Request-record completeness with stages

The share of requests recorded with their stages, times and documents, because a request without a record is provable neither on review nor on objection.

Requests closed within the published duration

The share against each service’s published duration, because a service without time measurement can neither be improved nor defended.

Proof-of-inspection or execution completeness

The share of visits or works closed with documented evidence (photo, location, time), because an item without evidence does not count in a financial review.

Approval and disbursement document completeness

The share of disbursement tied to a complete approval and document, because an observation is recorded at review and is hard to correct afterwards.

Access-log completeness

The share of beneficiary-record opens or edits logged with who performed them and when, because that is what is requested in any privacy review.

We announce no improvement or saving percentage, no satisfaction rate and no figures about market size or programme targets, and we claim no conformity with a national standard. What we measure is request-record completeness with its stages and times, the share of requests closed within the published duration, proof-of-inspection or execution completeness, approval and disbursement document completeness, and access-log completeness — figures read from your system about your operation.

Integration

Where the system lives in your entity

We connect what can genuinely be connected after inspecting the interface, and say plainly what cannot.

Odoo (finance, stock and purchasing)

Disbursement, approval and documents on the same financial entries, so figures are not run in two systems or copied by hand.

The primary integration

Government platforms and initiatives — after inspection

We connect only what provides an available interface, after inspecting and testing it; and we claim no compliance and no integration with a specific platform before that.

An explicit boundary

Sites, maps and field teams

Connecting sites to capture coordinates and evidence where a visit took place, after site names and numbers are unified — not before.

After sites are unified

E-invoicing and accounting

Connecting a purchase or service invoice to the statutory integration with a submission and response log, and reconciling disbursement with the accounts.

With a documented log

Beneficiary and reviewer communication

Messages and templates managed from settings with sending limits, the beneficiary’s consent to the channel before sending, and a record of what was sent.

With beneficiary consent

Boundaries

Where our scope stops — written before you ask

In the government sector, systems get conflated with accreditation, classification, clearances and decision-making, so the separation is written out plainly.

Accreditation, compliance and clearances

We are not a government entity, a regulator or an accredited supplier: we issue no compliance certificate, accreditation or security clearance, we claim no conformity with a national standard, and any requirement or classification is the entity’s responsibility and its process with the competent authorities.

Decision-making and eligibility

The system takes no decision: granting eligibility, approval, rejection and priority ranking are the authorised person’s decision, recorded with their name, time and reason, and we build no logic that decides in their place without written approval.

Platform integration and acceptance

We guarantee no acceptance by any entity or platform of a system or a request, and assert no integration before inspecting and testing the interface; if none is available we say so and promise nothing.

Regulatory advice and classification

We give no regulatory advice, classify no data and express no opinion on compliance; we implement and document the controls the entity requires, and classification, consents and the lawful basis are the entity’s responsibility as the data controller.

When what is needed falls outside our scope we say so in the assessment and refer a specialist or an accredited supplier instead of accepting it and learning at the expense of a service people depend on. That is written in the contract, not left to courtesy.

FAQ

Questions specific to entities

Direct answers on compliance, classification, decision-making, data and what we do not guarantee.

Are you an accredited supplier or compliant with digital government platforms?

We claim none of that. We are a systems company: we issue no compliance certificate, accreditation or security clearance, and we assert no conformity with a national standard or integration with a specific platform before inspecting its interface and confirming availability. Any compliance requirement, classification or permit remains the entity’s responsibility and its process with the competent authorities. Anyone telling you the system is “compliant and accredited” without showing you the interface and the test is making a promise they do not own.

Does the system grant eligibility or approve requests automatically?

No. The system records, it does not decide: it gathers the request, its documents and its stages, raises them to whoever holds the authority, and documents the decision, its reason and its time. We build no logic that grants eligibility, rejects an entitlement or ranks beneficiary priority without a declared human approval, because that is a statutory decision belonging to the entity and its responsibility — and putting it in an algorithm transfers responsibility to a program that does not hold it. If automated filtering rules are requested, they are built as published rules approved in writing and their effect is logged.

How do you handle beneficiary and applicant data?

By four rules: the data stays in the entity’s systems and remains its property; we use it for nothing beyond the scope of work; we share it with no third party; and we minimise what is collected to what the procedure genuinely needs. Permissions follow least privilege by role and unit, with an access log for every open or edit and a declared retention period. Data classification, consents and the lawful basis are the entity’s responsibility as the data controller; we implement the controls and issue no certificate and no regulatory opinion.

What usually stops systems projects in government entities?

Three things we see repeatedly, none of them technical: unwritten procedures — a request is run on personal knowledge, so the number of stages and the published duration are unknown; unapproved permissions — who genuinely holds approval is unclear, so a request stalls when one person is away; and non-unified data — names, titles and units in inconsistent forms, making any report hard. That is why we start by writing the procedure, approving the permissions and building a unified reference record, before any promise of a report or a dashboard.

Does a small entity need a full system?

No. It needs three things done well: a written procedure with published stages, a documented approval in its owner’s name, and a complete request record that can be read. An advanced beneficiary portal, connecting several platforms and dashboards add setup and entry a small team cannot carry and get abandoned after months so requests return to email. An abandoned project is worse than a small successful one — and we say so at assessment stage even when it means a smaller scope for us.

How do you handle classification and security clearance requirements?

We implement the technical controls the entity requires: least-privilege permissions by role and unit, an access log for every open or edit, a declared retention period, and separated test and production environments. Determining the classification level, clearances, consents and what suffices for compliance is the entity’s responsibility with the competent authorities; we issue no clearance and no certificate and express no regulatory opinion. That separation is written into the contract because it protects both sides and makes clear who answers for what.

What is out of scope?

Accreditation, compliance, security clearances and conformity certificates; regulatory advice and data classification; the decision to grant eligibility, reject or rank priority; guaranteed acceptance of a system or request by any entity or platform; integration with a specific platform before inspecting its interface; hardware, security gates and cameras; running operations on your behalf (we run the system, not the team); management or legal consulting; system and cloud licences (contracted in your name); and publishing market-size figures or national programme targets. We say all of this at assessment stage, before the contract.

Which entity type are you?

Tell us your entity type, the number of services or monthly requests and the number of units and users, and whether approvals or field inspection are managed, and we will come back with an assessment naming your type, the fitting scope — and what does not fit you.

  • An assessment that names your entity type
  • A written scope before any commitment
  • A plain statement of what is outside our scope
Request a proposal

Related topics

We are a systems implementation and integration company, not a government entity, a regulator, an accredited supplier or a classification or clearance authority: we claim no conformity with any national standard, no accreditation and no security clearance, we issue no compliance certificates, and we assert no integration with a specific platform before inspecting its interface and confirming availability. The system takes no decision: granting eligibility, approval, rejection and priority ranking are the authorised person’s decision, recorded with their name, time and reason, and we build no logic that decides in their place without written approval. We guarantee no acceptance by any entity or platform, and announce no improvement or saving percentage, no satisfaction rate and no figures about market size or programme targets. Beneficiary and applicant data stays in the entity’s systems, is never shared and is used for nothing beyond the scope of work; its classification, consents and lawful basis are the entity’s responsibility as the data controller. Durations shown are planning ranges, not commitments.