Customers email documents and phone for status updates, while staff copy requests between spreadsheets and systems. Employees use separate tools for leave, requests and approvals. Some organisations also want to turn a service they deliver by hand into a digital product other companies can use. In each case the process exists, but there is no single place where people log in and get it done.
Kemlat builds customer portals, employee portals and software as a service (SaaS) products, meaning software that customers use online by subscription. We define the user roles and what each one can see and do, design the admin panel your team will use to run the platform, and build the agreed features and integrations. Each release is tested against your real cases before it goes live.
How we work
- 01
Trace the procedure
We follow the procedure the portal will serve, step by step, with the people who run it today. We record each request type, approval, document and exception.
- 02
Compare building with buying
We check whether an existing product, or your current system with some configuration, can cover the need. A custom platform is recommended only where it is clearly the better option.
- 03
Design roles, flows and admin panel
We define user roles, permissions and the path of each request, and design the user screens and the admin panel together. For SaaS products we also design sign-up, subscription plans and the separation of each customer's data.
- 04
Build in stages and integrate
We build the agreed features in stages and connect the platform to systems such as ERP, CRM, email or electronic signature where agreed. Every stage ends with a working version for you to review.
- 05
Test and launch to a first group
We test with real sample cases, including permission checks and failed connections, and your team runs acceptance tests. The platform opens to a first group of users before everyone else.
- 06
Track use and improve
We follow sign-ups, request volumes, processing times and errors, and agree the next set of improvements with you.
What you receive
Roles and permissions model
A documented list of user types and what each one can view, create, approve or export.
Request flows and admin panel
Built flows for each request type, with an admin panel to manage users, settings and content.
Agreed features and integrations
The functions and system connections confirmed in scope, built and documented.
Activity log and alerts
A record of who did what and when, with email or in-app alerts at the key steps.
Acceptance testing and launch
Test results approved by your team and a staged opening to users.
Technical handover
Source code, deployment notes and an administrator guide handed to your team.
What changes for you
- Customers and staff check the status of a request themselves instead of calling or emailing.
- Every request has an owner and a visible stage.
- Managers see volumes and delays without asking anyone to prepare a report.
- If the platform is a product you sell, it can be offered to other organisations by subscription.
Where this service sits in the KEMLAT Method
Scope: Features and integrations are limited to those listed in the agreed scope; new feature requests are estimated and added as further stages. Running costs such as hosting, text messages or electronic signature are billed to you directly by each provider.
Questions clients ask
Should we build a portal or buy an existing product?
If a mature product covers most of your procedure, buying is usually faster and easier to run. Building makes sense when the procedure is specific to you, or when the platform is itself the product you sell. You get a written recommendation before design starts.
Can the portal connect to our current systems?
Most modern systems can share data through an application programming interface (API). For older systems we may use scheduled file exchanges instead. The method for each system is confirmed during design.
How is each customer's data kept separate in a SaaS product?
Each customer organisation's data is separated in the database and checked by permission rules on every request. We test this specifically before launch, because one customer seeing another's data is the most serious failure a SaaS product can have.
Can we start small and add features later?
Yes, and we recommend it. A first release that covers the most common requests lets you learn from real use before investing in the rest.
Related services
All servicesStart with a conversation
Tell us where you are today. We will suggest the right first step, with no obligation.