SmartLink
Business applications

CRM and HRM people actually use.

CRM implementation in Pakistan usually fails for a reason that has nothing to do with software: the stages in the system do not match the way deals actually close, so nobody updates it. HR systems fail differently, and the first disputed payslip is where it shows. SmartLink Services configures both from Karachi, across Microsoft Dynamics 365, Zoho, Odoo, SAP SuccessFactors and Oracle HCM, then integrates them with whichever system holds the money. What follows answers the questions buyers ask before scoping starts: what the work costs, how long a rollout runs, which platform suits which size of organisation, how payroll deductions and provincial tax are handled, and where any of it should be hosted.

Discuss this practice
CRM
Dynamics · Zoho · Odoo
HRM
SuccessFactors · Oracle HCM
Rollout
Pilot team first
Adoption
Measured, not assumed
Overview

A CRM only pays back when the pipeline reflects reality.

The most common reason a CRM fails is not the software. It is that the stages in the system do not match the way deals actually progress, so updating it feels like admin rather than work. Within a quarter the pipeline is decorative and leadership is back to asking for a spreadsheet.

We start from your sales stages, your qualification criteria and the reports leadership genuinely uses, then configure against those. Rollout goes to a pilot team first so the design meets reality while it is still cheap to change. Adoption is measured after thirty days and reported, because a CRM nobody updates is worse than no CRM at all.

HR systems fail differently. Employee data spread across spreadsheets turns every payroll into a negotiation. One record per employee and one approval path per event fixes more than any feature list, and it is where we start.

Scope

What CRM & HRM covers

CRM and HRM are handled by the same team because the reporting layer, the integrations and the adoption problem overlap.

What the work covers

  • Sales stage and qualification model designed around your process
  • Lead, account, opportunity and quotation configuration
  • Service ticketing, SLA rules and case routing
  • Employee master data, org structure and position hierarchy
  • Attendance, leave, appraisal and payroll configuration
  • Pilot rollout, then phased onboarding with adoption measurement

What you get at handover

  • Configured pipeline and stage definitions
  • Dashboard set for reps, managers and leadership
  • Payroll parallel-run comparison and statutory reports
  • Data import of existing accounts, contacts and employee records
  • Admin handover documentation and team training

Typically involves

Discuss this practice
Services in this practice

Every CRM & HRM service

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 → Business applications

Employee & customer portals

Self-service portals over ERP and HRM so requests stop arriving as email.

Open service page →
01

Deciding which system holds the customer

Almost every CRM engagement meets the same question in its second week. The ERP holds customers, prices, credit limits and invoices. The CRM wants to hold prospects, quotations and accounts. Some of those records are the same thing under two names, and if both systems may create them you will have duplicates within a quarter. The answer is a written register naming the system of record for each object, plus the direction each field flows. It takes an afternoon and prevents a year of reconciliation.

Conversion is the interesting edge. A prospect exists only in the CRM until it becomes a customer, at which point the ERP has to create an account with credit terms, tax registration and payment conditions attached. Deciding where that handover happens, who approves it and what the CRM shows afterwards carries real operational weight. Get it wrong and sales teams start creating accounts directly in the finance system to get an order out, which is precisely the behaviour the integration was meant to remove.

Reporting inherits the same problem. Leadership will eventually ask why the pipeline forecast and the revenue report disagree, and the honest answer is usually that they measure different things at different moments under different currency conversion rules. Agree in advance which system produces which number, whether pipeline is reported at gross or expected value, and what happens to a deal that is won but not yet invoiced. Numbers that cannot be reconciled get ignored, and once ignored they stop being maintained.

  • A register naming the system of record for customers, prices, credit terms and quotations
  • The prospect to customer conversion point defined, with a named approver
  • Field level flow direction agreed, so neither system silently overwrites the other
  • One stated source for each leadership number, including currency conversion rules
  • A duplicate detection and merge rule agreed before any historic data is loaded
02

What has to be settled before an HR system is configured

Employee numbering and effective dating are the two foundations, and both are painful to revisit. A single permanent employee number that survives transfers, rehires and changes of contract is worth insisting on, even where the current payroll reissues numbers freely. Effective dating is the subtler one. If the system cannot record that a salary changed on the first of a month while the approval happened on the ninth, retrospective calculations will be wrong and every backdated promotion becomes a manual adjustment somebody has to remember.

Organisational structure has a similar fork. Modelling by position, where a post exists independently of whoever occupies it, supports vacancy reporting, acting arrangements and headcount budgeting properly. Modelling by person is simpler to set up and collapses the first time somebody holds two roles or a post sits empty for three months. Choose deliberately, with the head of human resources present, because rebuilding the structure after a year of history means reprocessing everything that hangs from it.

Leave accrual and payroll rules deserve the same treatment. Opening balances, carry forward limits, encashment, the treatment of unpaid absence and the definition of a working day all sound like details until the first cycle produces a figure an employee disputes. We configure to the rules your organisation actually applies, documented and signed by the people accountable for them. Statutory interpretation stays with your own advisers, because we build and integrate systems and are neither an employment law firm nor a tax adviser.

  • A permanent employee number that survives transfer, rehire and change of contract
  • Effective dating on every event, so backdated changes calculate rather than require adjustment
  • Position based or person based organisational structure chosen deliberately and early
  • Leave accrual, carry forward and encashment rules documented and signed before configuration
  • Statutory rules confirmed by your own legal and tax advisers, then configured to that instruction
01

What CRM and HR software costs in Pakistan

Two numbers make up the total and they behave differently. Licence or subscription is set by the vendor, priced per user per month, usually in dollars, and it recurs for as long as you use the system. Implementation is local effort billed in rupees, largely one off, with a smaller tail for support and change. For reference, subscription ERP in Pakistan is commonly quoted at around PKR 2,500 per user per month, while international CRM vendors price seats on their own published list and convert at whatever the rate is that day.

Market ranges are most useful at module level. HR and payroll configured inside a core systems programme is published at PKR 200,000 to 400,000. Multi location capability runs PKR 200,000 to 500,000, and a mobile application, whether that is field sales capture or employee self service, is quoted at PKR 400,000 to 800,000. Where a customer system is built rather than configured it becomes a custom web application, and market pricing for those sits at PKR 200,000 to 1,000,000 and upwards, depending on how much of the requirement is genuinely new rather than a variation on something already solved.

Five things move the figure once scoping is honest. User count and edition, because vendors gate automation and reporting behind tiers you discover late. The number of distinct sales processes: one pipeline is a configuration exercise, four business lines with different qualification rules is a project. Payroll population and rule complexity, where allowances, shift premiums, overtime and staff spread across provinces each add a cycle of testing. Integration to the ERP, to attendance hardware and to the bank file. Then the condition of what you already hold, which in this practice usually means duplicate accounts sitting in a shared mailbox and employee records in a spreadsheet with three owners and no history.

Extension work after go live is billed by the hour. Market rates for full stack development in Pakistan run PKR 3,500 to 8,000, with junior work at PKR 500 to 1,000, and Pakistani rates sit roughly 60 to 80 percent below Western equivalents, which is why offshore buyers see USD 15 to 50 quoted for comparable skills. None of these figures is our quotation. A real number follows discovery, once the pipelines, the payroll rules and the state of the data have been written down and agreed.

  • Subscription per user per month, set by vendor tier rather than by us
  • Configuration effort, driven by the number of distinct sales processes
  • Payroll rule complexity: allowances, shifts, overtime and multiple provinces
  • Integrations to the ERP, to attendance hardware and to the bank file
  • Deduplication and record cleaning, priced before anything is loaded
02

How long a CRM or HRM rollout takes

Reported timelines follow the same shape as any core system. A focused single company go live is reported at six to twelve weeks. An SME rollout across more teams and more modules is reported at three to six months. Large organisations, with several entities and a payroll population in the thousands, are reported at nine to twelve months. A customer system for one team with a single pipeline sits at the short end of that; an HR rollout with attendance hardware on three sites sits at the long end.

Payroll carries a constraint the rest of the work does not, and it is a calendar rather than a plan. Validation runs against real pay periods, so each cycle costs a month of elapsed time regardless of how much effort is thrown at it. Two clean cycles is the usual bar before an old system is retired. That arithmetic cannot be compressed, and a proposal that claims otherwise has not thought about what happens if the first cycle disagrees.

Slippage comes from the same three places every time. Scope widens, because every manager asks for one more field and nobody is placed to refuse. Data turns out worse than described: accounts duplicated across shared mailboxes, leave balances that one person in payroll can explain and no one else can. Availability is the last and the hardest of the three. Sales teams are measured on quota rather than on attendance at configuration workshops, and freeing them takes a decision from someone senior enough to accept a slower month.

Piloting one team first adds a fortnight to the plan and reliably removes considerably more than that from the far end of it, which is the one trade in this practice that is never close.

  • Focused single company go live reported at six to twelve weeks
  • SME rollouts at three to six months, large multi entity work at nine to twelve
  • Two parallel payroll cycles, each costing a calendar month that cannot be shortened
  • Scope changes reset the test cycle rather than extending it
  • Sales and payroll availability agreed by name and days per week before baselining
03

Which platform fits: Dynamics 365, Salesforce, Zoho and the HR systems

Microsoft Dynamics 365 suits organisations already standardised on Microsoft. If mail and files sit on Microsoft 365, if the finance team lives in Excel and leadership wants Power BI, adoption comes easier because the tools already look familiar. Licensing runs per application, which is efficient for two modules and less so for seven. The recurring failure is extension drift: customisation is easy, so it accumulates quietly, and upgrades slow down in proportion.

Salesforce is the deepest of the three and the most demanding. It suits large sales organisations with many products, complicated territories and a full time administrator inside the business, and its marketplace covers most requirements without new code being written. Cost and dependency are the strains. Seats are priced in dollars, the platform expects continuous administration to stay useful, and the local partner market in Pakistan is thinner than for Microsoft, which matters on the day you need somebody on site.

Zoho is where a good number of Pakistani SMEs should honestly start. The entry price is low, the suite is broad enough to cover sales, support and marketing without a second purchase, and a small team can be productive inside a month. Complexity is the limit. Advanced configuration becomes intricate faster than the marketing suggests, and integration with anything outside Zoho usually needs real API work rather than a connector and an afternoon.

Odoo CRM deserves a mention for a structural reason rather than a functional one. Where the ERP is already Odoo, the customer records share one database, and the integration problem that consumes a large share of a typical CRM budget simply does not arise.

HR and payroll follow different logic. SAP SuccessFactors and Oracle HCM Cloud are the serious choices for large organisations that need one HR policy across countries, proper position modelling and reporting an auditor will accept. Neither arrives with Pakistani statutory payroll ready to run, so payroll is localised, bolted on, or handed to a local product built for it. Locally written payroll systems handle income tax withholding, EOBI and provincial social security natively, and are usually weaker at organisation modelling, performance and learning. Many Pakistani groups end up with a global HR core and a local payroll engine beneath it. The interface between the two is the real project, and it is where the budget quietly goes. We resell none of these licences, and the shortlist we write names what we set aside and why.

  • Dynamics 365 where the organisation is already standardised on Microsoft
  • Salesforce where sales is large, complicated and has a full time administrator
  • Zoho where the budget is tight and the sales process is straightforward
  • SuccessFactors or Oracle HCM for policy across countries, with local payroll beneath
  • The HR core to payroll interface designed and costed before either is bought
04

Payroll deductions, sales tax on services and employee data

Payroll in Pakistan carries several statutory tracks, and a system that handles only the salary calculation is not a payroll system. Income tax is withheld from salary monthly and reported. EOBI contributions are calculated and remitted. Provincial social security applies through the institution for the province the employee works in, which for a Karachi employer means Sindh. Rates, thresholds and slabs change with the Finance Act, so we configure to what your tax adviser confirms in writing, and we re-check that configuration at the start of each tax year rather than assuming last year's table still holds.

Sales tax on services is administered provincially. The Sindh Revenue Board covers Sindh, the Punjab Revenue Authority covers Punjab, other provinces have their own authorities, and sales tax on goods sits federally with the FBR. For a services business in Karachi invoicing clients in Lahore, which authority applies to which line is a classification question, and it belongs to your tax adviser rather than to us. What the system has to do is hold the correct registrations, apply a tax code per service line instead of per customer, and produce an extract that reconciles to the return without anyone rekeying it.

Where the customer system raises invoices rather than the ERP, section 3(9A) of the Sales Tax Act is relevant in the same way it is in retail. Tier-1 retailers and other notified persons integrate with the FBR computerised system for real time reporting, and the invoice reference number and QR code that FBR returns have to appear on the document. The decision worth taking early is which system is permitted to raise a tax invoice at all. Two systems issuing against one registration produces a reconciliation nobody enjoys and an audit question nobody wants.

Employee data brings a different obligation and it is mostly about restraint. Payroll files hold CNIC copies, bank details, salary history and sometimes medical claims. Decide who may see salary, who may export a full employee list and how long records are kept after somebody leaves, then have the system enforce it rather than an administrator remember it. Where a payroll bureau is involved, the responsibility split gets written down before any data moves. We hold no payroll data of yours, and we are neither tax advisers nor employment lawyers, which is why every statutory rule we configure has a written instruction sitting behind it.

  • Income tax withholding, EOBI and provincial social security configured to written advice
  • Configuration re-checked at the start of each tax year rather than assumed forward
  • Tax code applied per service line, with provincial registrations held correctly
  • One system nominated to raise tax invoices against a given registration
  • Salary visibility, bulk export and retention enforced by the system, not by memory
05

Cloud or on premise

For customer systems the question is largely settled. Salesforce and Zoho are cloud only in any form worth running, and Dynamics 365 is cloud first, so choosing your own servers means either building something or running an older product, and both cost more than the subscription you avoided. The useful version of the question is where the data physically sits and who can reach it, and any serious vendor will answer that in writing if you ask before signing.

HR and payroll is where the argument remains live, and it is about salary data rather than about technology. Boards object to payroll leaving the building, particularly in family owned groups where senior pay is closely held. That is a legitimate position with a price attached: your team patches the server, your team tests the upgrade, your team takes the call at two in the morning when the run fails the night before payday, and your team owns the recovery test nobody has scheduled.

A cloud HR core with payroll calculated locally is the common middle in Pakistani groups, and it is defensible. It also doubles the monitoring surface, because there are now two systems and an interface between them, and the interface fails more often than either system does. Field sales settle the last part of the decision. A mobile application has to capture a visit without a signal in Sukkur and sync when the phone finds one, and that requirement points to cloud with offline capture rather than to a server in your own building.

  • Most customer platforms are cloud only, so the real question is data location
  • On premise payroll where a board policy keeps salary data inside the building
  • The cost of patching, upgrade testing and recovery counted in any on premise case
  • Hybrid HR and payroll designed with the interface monitored, not assumed
  • Offline capture for field sales tested outside the major cities
How we deliver

Delivering CRM & HRM

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

Adoption is the only measure that settles the argument

Every claim in this practice reduces to one test. Six months after go-live, does the pipeline show what is genuinely happening, and does payroll run without a spreadsheet beside it. If the answer is yes, the configuration matched the work. If it is no, no amount of reporting will disguise that for long.

That test is why the sequence here looks as it does. Small first rollout, a real cycle, honest measurement, fields removed rather than added, administrators trained inside your organisation. It is unglamorous, and it is considerably cheaper than the alternative, which is a second implementation in three years with the same requirements and a far more sceptical audience.

SmartLink Services implements and integrates these systems, migrates the data into them, and either supports them afterwards or hands them over. Where the honest finding is that your existing platform is capable and the real problem is process design or the way the stages were defined, we will say so and quote for fixing that instead.

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

CRM & HRM: the questions we are asked

There are two lines to budget. Vendor subscription is per user per month and set by the vendor, and implementation is local effort. Published market ranges put HR and payroll configuration at PKR 200,000 to 400,000, a mobile or self service application at PKR 400,000 to 800,000, and a customer system built rather than configured at PKR 200,000 to 1,000,000 and upwards. Our own figure follows discovery.

Reported timelines put a focused single company go live at six to twelve weeks, an SME rollout at three to six months, and a large multi entity programme at nine to twelve months. Payroll adds a constraint of its own. Validation runs against real pay periods, two clean cycles is the usual bar, and a calendar month per cycle cannot be compressed by effort.

For five to fifteen people working one pipeline, Zoho is usually the sensible starting point on price and speed of setup. Dynamics 365 makes more sense where the organisation already runs Microsoft 365 and leadership wants Power BI. Salesforce is rarely the right first purchase at that size. If your ERP is Odoo, use the customer module that shares its database.

Statutory handling, mostly. A product written abroad will calculate a salary correctly and still be unable to produce EOBI contributions, provincial social security or a monthly withholding statement in the format required here. Bank file layouts for local salary disbursement are the other common gap. Leave, attendance and appraisal are broadly similar wherever the software was written.

The technical answer is usually yes, since major vendors run better security than most in house server rooms. The real questions are contractual. Where does the data sit, who inside the vendor can reach it, what happens at the end of the contract, and can you take a full export in a format that opens elsewhere. Get those answers in writing beforehand.

One platform is simpler to administer and cheaper to licence, and it is the right answer when both requirements are ordinary. Two makes sense when either side is demanding: a large sales organisation with complicated territories, or a payroll heavy with shift and allowance rules. What matters more than the number is that one system owns each record and the interface is designed rather than improvised.

Yes, and it should be, because a visit typed up in the evening from memory is worth less than one recorded at the gate. Check offline capture specifically. Coverage outside the major cities is uneven, so the application has to store a visit without a signal and sync later. A purpose built mobile application is quoted in the market at PKR 400,000 to 800,000.

You should be able to leave, and that is worth establishing before you arrive. We ask for the export path during selection: full employee master, salary history, leave balances and payroll results, in a format that opens outside the vendor product. Where a supplier cannot demonstrate that on request, treat it as a commercial risk rather than a technical detail.

Pipeline not reflecting reality?

Tell us how your team sells and where the CRM or HR system gets in the way. We will show you what a configuration built around your process looks like.

Book a consultation See all practices