Services are configuration

This course is for MDA officers and analysts who set up e-Services in the back office. By the end you will be able to design a complete service, test it, have it approved and know what else it needs before it counts as done.

One product, many ministries

Pamodzi is one e-Services product used by many ministries, departments and agencies (MDAs). The core of the platform never names or assumes a particular ministry. What makes a ministry's service different is its configuration:

the application form;
the process: the steps, and the role that does each;
the fees;
the documents the applicant must upload;
the output documents: certificates, licences and letters;
the capabilities the service uses.

A new service should need nothing else. Code is needed only when a genuinely new capability is missing, and then it is built generically so other ministries can use it too. For example, the shop works for any ministry that sells products, and name reservation works for any registry.

This matters to you as a designer. If you find yourself thinking "this needs a developer", first check whether an existing step type, field, fee type or capability already does the job. Usually one does.

Where you work

Services are designed in the back office under Service Management → Manage Services. Opening a service shows the service editor. Its tabs are the parts of a service:

Tab	Purpose
Service settings	The public service passport: name, providing MDA, type, status, description, who can apply, fee text, processing time, validity, legal references
Form builder	The application form
Service process	The workflow
Supporting documents	What the applicant uploads
Output documents	Templates for what the service issues
Transaction codes	The revenue code for posting revenue
Fees	How the service charges
Versions and approval	Drafts, checks, test submissions, approval
Change history	Who changed what

You need a service administration role to see these screens. The server decides what you may change. A button you can see is not a permission; a button you cannot see is not the only protection.

The service passport

The Service settings tab describes the service to citizens. Write it in plain English:

Service name: what the citizen is asking for, for example "Application for a trading licence".
Service provider (MDA): the ministry that owns the service.
Service type: Public services appear on the national portal; Internal services are visible only to officers.
Status: Active accepts applications; Inactive hides the service from applicants.
Description: what the service does and who it is for.
Who can apply: for example individuals, organisations.
Fee: the text citizens read, such as "ZMW 250.00". The amount actually charged is set on the Fees tab.
Processing time: for example "30 days". The platform uses it for due dates and overdue warnings.
Validity: for example "1 year from the date of issue". Issued documents carry this validity, and an expired
licence fails verification.
Legal references: the Act or statutory instrument.

The same tab also holds smaller cards for edited services, such as a guard against a second open application for the same plot, and intake windows (periods when applications are accepted).

Four ways to start a service

By hand. Manage Services → Create service, then fill each tab.
From a ready-made design. Service Management → Ready-made services (administrators). The first design is
event registration: capacity, fee, approval and an attendee list. You choose the ministry and the platform creates an ordinary draft service that you finish in the editor.
With the AI Service Builder. On Manage Services, administrators see AI Service Builder while the AI feature
is switched on. Choose the responsible MDA, name the service and upload the statutory instrument or Act (PDF, Word or text, at most 10 MB). The assistant drafts the application form, the process, the fees and the passport. It can also draft output document templates; these are marked "AI-generated - check before use". The generated service is saved as a draft: you review it, and another administrator approves it before it goes live. If the assistant cannot design a workflow from the document, it uses a standard one and tells you to check the steps.
By import. The services of the legacy catalogue were imported with the platform's importer and are edited like
any other service.

Whichever way you start, the result is the same kind of service, edited in the same editor and published the same way.

A worked example

Suppose a ministry asks for an "Example Vendor Permit". Before opening the editor, gather:

the law that creates the permit (for legal references and the validity);
who may apply, and what the officer needs to know to decide (the form);
who reviews, who approves and who decides (the process and roles);
the fee and whether it varies (the fees);
the documents an applicant must provide (supporting documents);
what the permit looks like (the output template).

With these answers you can configure the whole service without code. The following lessons take each part in turn.

Who does what

Service designers prepare a draft and submit it with a change summary.
A second administrator approves or rejects the version. The person who made, edited or submitted a version can
never approve it.
Developers are needed only for a missing generic capability or a ministry module.
Testers write the service's end-to-end journey and generate its documentation.

Check your understanding

Which six things make up a service's configuration?
Where in the back office do you design a service?
What is the difference between a public and an internal service?
Where is the amount actually charged set, as opposed to the fee text citizens read?
What happens to a service generated by the AI Service Builder before it reaches citizens?
Who may approve a version that you submitted?