SmartLink
Business applications

Employee self service and customer portals in Pakistan

An employee self service portal in Pakistan is bought to empty an inbox, and it succeeds or fails on whether the request that arrives can actually be answered without a person. SmartLink Services builds portals from Karachi over existing ERP and HRM systems, in React and Node against REST interfaces, with single sign on where a directory exists. What follows is the commercial part: market rates for building one, how long a first release takes, and the choice that should be made before any of that, which is whether your existing software already ships the module you are about to pay to rebuild.

Discuss this service
Access
Web \u00b7 mobile browser
Auth
SSO where available
Backend
Existing ERP / HRM
Overview

A portal has to remove a step

Routine requests are expensive because of where they land, not because of what they take. A customer asking for a statement, an employee asking for a salary certificate, a dealer asking whether an order has shipped: each is a small task that arrives as an interruption to somebody already doing something else. Portals move those requests to the person who wants the answer, and they succeed or fail on whether that person finds the answer faster than sending the email would have taken.

Everything else follows from that single test. If the portal shows an order status lagging the warehouse by a day, people will telephone anyway and you now maintain two channels instead of one. If it shows a leave balance the employee disputes, it generates contact rather than removing it. Live data from the system of record, or an honest label saying when the figure was last refreshed, is what separates a portal that reduces load from one that quietly adds to it.

Access is the other half of the design. External users and employees see only what belongs to them, enforced on the server rather than by hiding a menu item, and administrative access is kept separate from the underlying business systems. A portal is a controlled window onto enterprise data, which means the permission model deserves at least as much attention as the screens, and usually gets rather less. Screens are visible and get reviewed by everybody. Permission rules are invisible until the day somebody sees a record that was never meant for them.

Scope

What Employee & customer portals covers

Everything below is agreed in writing before any crm & hrm work starts, so both sides know what is in and what is not.

What the work covers

  • Leave, expense and document request workflows
  • Payslip and letter self-download
  • Customer order status, invoice and statement views
  • Support ticket raising and tracking
  • Single sign-on against your directory
  • Mobile-first layouts for shop floor and field staff

What you get at handover

  • Deployed portal with role-based access
  • Workflow definition documents
  • SSO configuration notes
  • Usage analytics dashboard
  • Source code and deployment guide

Typically involves

REST APIs
Discuss this service
01

Designing for a phone held on a shop floor

A large share of portal users have no desk. They are on a production floor, in a warehouse, in a vehicle or standing at a customer site, using a personal phone on a connection that comes and goes. Designing for that is not a matter of making the desktop layout narrower. It changes what belongs on the first screen, how many taps a task takes, and how much the page is allowed to weigh before it stops being usable.

Practical decisions follow from it. Large touch targets, because hands are gloved or wet. Few form fields with sensible defaults, because typing on a phone is slow and error prone. Clear confirmation when something has been submitted, because a user who is not certain will simply submit again and create a duplicate. Files sized for a mobile connection, since a payslip that takes thirty seconds to open will be requested from HR instead. The portal has then cost money and changed nothing.

Shared devices deserve an explicit decision as well. A terminal on a plant floor used by an entire shift cannot hold a session open, needs a short timeout, and needs a quick way to identify the person without a long password typed on an awkward keyboard. Where that situation exists we design for it directly rather than pretending every user has a private device in their pocket. Getting this wrong produces the familiar arrangement where one worker signs in and the rest of the shift uses that session all day.

  • A first screen built around the two or three tasks the user actually came to do
  • Large touch targets and short forms with sensible defaults already filled
  • Page weight kept low so the portal remains usable on a poor mobile connection
  • Explicit confirmation after submission, so nobody creates a duplicate request
  • A defined approach for shared terminals: short sessions and fast identification
02

Single sign on and leaver accounts

Every portal starts with a question about identity. Employees usually have one already in a corporate directory, and reusing it is the right answer: one password, one reset process, and one place where access is removed. Building a separate login for the portal creates a second set of credentials that nobody governs, and those are precisely the accounts that survive a resignation by several years without anybody noticing. They also carry whatever password policy the portal was built with, which is rarely revisited after launch.

Customers and dealers are different. They rarely sit in your directory, so accounts are created and managed inside the portal, which means the joiner and leaver process has to be built rather than inherited. Somebody at the customer moves on and their access should go with them, and that only happens if account ownership is attached to the commercial relationship and reviewed on a cycle somebody owns. Asking a customer to confirm their own user list once a year is unglamorous, and it works better than any alternative we have seen.

Whichever route applies, authorisation is enforced at the interface layer rather than in the browser. A hidden link is not a control. Every request for a record checks that the caller is entitled to that specific record, and external access is logged so that a question about who viewed a document has an answer. Where an ERP sits behind the portal, its credentials never travel anywhere near the client. Anything the browser can reach should be treated as something an interested person will eventually try to reach directly.

  • Employee access through the corporate directory, so removal follows the leaver process automatically
  • Customer and dealer accounts owned by a named person, reviewed on a set cycle
  • Authorisation checked on every request at the server, never by hiding navigation
  • Credentials for enterprise systems held by the portal service rather than by the browser
  • Audit logging of external access to documents and records
01

What a portal costs to build in Pakistan

Portals are priced as custom applications rather than as products, and published market ranges for a custom web application in Pakistan run PKR 200,000 to 1,000,000 and upwards. The spread is genuine. At the bottom sits a read only portal showing payslips and leave balances to staff who already have accounts. At the top sits a customer facing system handling orders, statements, document upload and support tickets against a live ERP, with an audit trail somebody will be asked to produce. For scale, a straightforward business website is published at PKR 80,000 to 200,000 and a dedicated mobile application at PKR 400,000 to 800,000.

Workflow count is what actually drives the estimate. A leave request that goes to one approver is a form. A leave request that routes by department, escalates when the approver is away, deducts a balance, notifies payroll and produces an entitlement statement is a small system. Count the routes rather than the screens. Single sign on against a corporate directory is the second item and it is consistently underestimated, because the directory is somebody else's system and access to test it arrives on their timetable.

Two costs sit outside the build and belong in the comparison. Hosting and the security work that follows anything facing the internet: certificates, patching, a penetration test where the client requires one, and a plan for what happens when a vulnerability is announced in a library the portal uses. Then support, quoted against market hourly rates for full stack development in Pakistan of PKR 3,500 to 8,000. Those rates sit roughly 60 to 80 percent below Western equivalents, which is why offshore buyers see USD 15 to 50 quoted for comparable skills. All of this is market pricing. Our figure follows discovery, once the workflow list and the back end interfaces are known.

  • Priced per workflow route rather than per screen, since routing carries the complexity
  • Single sign on scoped with the directory owner, whose availability sets the pace
  • Back end interface readiness assessed before the front end is estimated
  • Hosting, certificates, patching and security testing budgeted as continuing cost
  • Support quoted against hourly market rates rather than folded into the build price
02

How long a portal build takes

A first release covering three or four workflows is a matter of weeks rather than months, and reported timelines for a focused single company go live of six to twelve weeks describe it well. Portals suit incremental delivery better than most enterprise work, because each workflow is separable and a portal with four working requests is useful on the day it ships, unlike an ERP module that is useless until complete.

Back end readiness sets the pace far more than front end work does. Where the ERP or HRM exposes the data through documented interfaces, the build is quick. Where it does not, the first job is creating that access safely, and safely is the operative word. A portal facing the internet must never talk to the production database directly, so a service layer stands between them, exposing only what the portal needs and nothing more. Building that layer is real work and it belongs in the plan rather than in a surprise.

Security review and directory access are the two things that add elapsed time nobody enjoys explaining. Single sign on needs configuration on the client's own identity system, which usually means a queue behind somebody else's priorities. Where an organisation requires a penetration test before a portal is exposed, book it early, because testers are scheduled weeks ahead and a finding raised in a report has to be fixed and retested before launch.

  • A first release of three or four workflows delivered in weeks, then extended
  • Back end interface readiness assessed before any timeline is quoted
  • A service layer built between the portal and the production system rather than direct access
  • Directory and single sign on configuration queued with the team that owns it
  • Security testing booked early, with time allowed to fix findings and retest
03

Using the vendor self service module or building a portal

Check what you already own before commissioning anything. SAP, Oracle, Odoo and most current HR products ship an employee self service module, and where it covers your requirement it is the cheaper answer: no interface to build, no separate authentication, no second system to patch, and leaver access disappears when the employee record is deactivated rather than when somebody remembers. Organisations regularly pay to build a portal that duplicates a module included in a licence they are already renewing.

Three situations make a build the better answer. Customer facing work is the first, since ERP vendors are consistently weaker outside their own user base and a portal your customers use is part of your commercial presence rather than an internal screen. More than one back end is the second, where staff reach HR data and ERP data through one login and no single vendor module spans both. The third is a genuinely specific requirement: a workflow the vendor module cannot express, or an approval chain that reflects how your organisation actually decides.

Device reality decides more of this than feature lists do. A shop floor supervisor using a shared phone in poor light, with one hand, next to a machine, is a design constraint rather than a preference. Vendor modules are frequently built for a desk, and a responsive layout is not the same as a screen designed for that supervisor. Where that is the population you serve, a build usually earns its cost. Where it is office staff at desks, it does not.

Whichever route is taken, the security position is the same. Anything facing the internet reaches the production system through a service layer exposing only the fields it needs, access is granted by role rather than by page, and leaver handling joins the joiner and leaver process rather than somebody's memory. We tell clients when the module they already licence is adequate, because a portal nobody needed is an expensive way to reach the same inbox.

  • The self service module included in your licence checked before anything is commissioned
  • A build where customers are the audience or where several back end systems are involved
  • Screen design tested on the device the user actually holds, in the place they hold it
  • A service layer exposing only required fields, whichever route is chosen
  • Leaver access joined to the joiner and leaver process rather than to memory
How we deliver

Delivering Employee & customer portals

Customer and people systems fail on adoption rather than on features. So the weight in these six steps sits on the pilot and the first real cycle, not on the build.

  1. 01

    Discover

    Sit with two reps through a week of their pipeline updates and with payroll through one close. The stages people describe in a meeting and the stages deals actually pass through are different things.

  2. 02

    Blueprint

    A register names which system owns customers, prices and credit terms, and where a prospect becomes an account. Employee numbering, effective dating and the leave accrual rules are settled in the same document.

  3. 03

    Build

    Pipeline stages, qualification criteria, approval routes and payslip layouts get configured against that register. Fields nobody named an owner for are left out, because every extra field is one more reason not to update the record.

  4. 04

    Test

    Payroll is proved by parallel run, two cycles, every variance explained by a rule rather than dismissed as small. CRM testing follows the deal from lead through quotation to the invoice raised in the ERP.

  5. 05

    Go live

    One pilot team first, with a sceptic in it, then waves. Payroll switches at a tax year boundary where the local framework gives one, so year to date figures stay clean.

  6. 06

    Run

    Adoption is measured at thirty days: records updated within a day of the activity, mandatory fields left at default, time a manager spends assembling the weekly review. Unused fields are then removed.

Working together

A portal will not rescue a broken process

If order status inside the business is uncertain, a portal will publish that uncertainty to your customers at speed. If leave balances are disputed today, self service will turn a slow trickle of queries into a fast one. The portal is a window, and a window is only worth fitting when there is something worth looking at behind it. Where we find that the underlying data or process is the real problem, we will say so and recommend fixing that first.

Where the back office is sound, this is some of the most immediately useful work we do. Requests that used to arrive as email arrive as records with owners. Questions that used to interrupt somebody get answered by the person asking them. And there is a log of who accessed what, which turns out to matter far more than anyone expects the first time a customer disputes having received a document.

Credentials

Accreditations behind CRM & HRM

These systems hold salary data and customer records at the same time, so the questions we are asked are about access control as much as about platform accreditation.

Oracle

Partner

Oracle HCM Cloud for employee master data, absence and payroll, sitting on an Oracle database we also administer. Customer records held in EBS stay the source for credit terms and pricing.

Microsoft

Partner

Dynamics 365 Sales and Customer Service configuration, Power Automate for leave and expense approvals, and Entra ID sign in so a leaver loses CRM access when human resources ends the record.

Google

Partner

Workspace calendars and mail threaded onto the account record, so a rep's meeting history sits on the opportunity instead of in a personal inbox. Google Cloud where the CRM is self hosted.

FBR digital invoicing

Compliant integrations

Quotations approved in the CRM become sales orders and then tax invoices in the ERP, which is where FBR submission happens. The invoice reference number is visible back on the opportunity.

HIPAA

Compliant practices

A hospital service desk using a CRM sees patient contact details, so views are cut to the minimum necessary, exports are restricted and logged, and a business associate agreement is signed first.

Client words

What CRM & HRM clients say

Comments from people who run crm & hrm systems day to day.

  • Timesheets were the thing everybody hated, so that is where they started. Entry now takes seconds on a phone and the utilisation numbers are current rather than a week old. I can see an engagement drifting while there is still something I can do about it.
    Managing Partner Professional services practice
  • Our cost reports used to show what we had paid, never what we had committed. Once the subcontract orders and approved variations started registering as commitment, the forecast stopped flattering us. It was uncomfortable reading for a month and then it became the most useful number we have.
    Chief Financial Officer Construction and contracting firm
  • The team spent two days on the floor before they proposed anything, which I did not expect. They noticed that our scrap was being written off as a variance instead of recorded as returning metal, and that one change altered how we look at recovery on every press.
    Plant Manager Aluminium extrusion operation
Questions

Questions about Employee & customer portals

Portals are priced as custom applications, and published market ranges for a custom web application in Pakistan run PKR 200,000 to 1,000,000 and upwards. A read only payslip and leave portal sits at the bottom. A customer facing system over a live ERP sits at the top. A dedicated mobile application is quoted separately at PKR 400,000 to 800,000. Our figure follows discovery.

A first release of three or four workflows takes weeks, and reported timelines for a focused single company go live of six to twelve weeks describe it well. What sets the pace is the readiness of the back end interfaces, not the front end. Directory access for single sign on and any required security testing both need booking early.

A screen where staff handle their own routine requests instead of sending them to HR: applying for leave and seeing the balance, downloading payslips and letters, updating personal details for approval, submitting expenses and checking where a request has reached. It removes the questions that arrive by message and never get recorded, and it gives each request a date and an approver.

Yes, and for a plant workforce it is the only realistic access. Design for the device rather than shrinking a desktop layout: large targets, few fields per screen, and a login that works on a shared phone in poor light. A mobile browser covers most requirements. Where offline capture or the camera is genuinely needed, a dedicated application is the honest answer.

It can be, and the design decides it rather than the platform. The portal reaches the production system through a service layer that exposes only the fields it needs, never the database directly. Access is granted by role, salary visibility and bulk export are restricted deliberately, and leaver access is removed through the joiner and leaver process rather than by memory.

They can request the change and they should not be able to apply it. Bank detail changes are the classic payroll fraud route, so the request goes to a second person for approval, the previous value is retained in the audit trail and a notification goes to the employee on the record. Any supplier who offers self service bank changes without that chain has not thought it through.

More in CRM & HRM

More CRM & HRM services

Business applications

CRM implementation

Pipeline, quoting, service and reporting configured around how your sales team really sells.

Open service page → Business applications

HRM & HCM systems

Employee master data, attendance, leave, appraisal and payroll in one system of record.

Open service page → Business applications

Payroll processing systems

Payroll runs, statutory deductions, bank files and payslip distribution, automated and reconciled.

Open service page →

Still answering routine requests by email?

Tell us what you run today and where employee & customer portals is causing you trouble. The first conversation is a consultation rather than a pitch.

Book a consultation All crm & hrm