Building a Scalable HR Operations System

Start with the operating model, not the tool

Instead of asking how a process should work in Salesforce, I focused on broader product questions: what experience teams should have, where friction lived, how information should move across the organisation, and which workflows truly deserved standardisation.

That shift kept the conversation centred on shared business outcomes rather than a collection of disconnected feature requests.

Turn discovery into strategy

Across workshops, the same themes repeated: no complete customer lifecycle view, duplicated information, fragmented reporting, and limited automation because systems could not communicate well.

I converted those patterns into a capability-led strategy built around customer lifecycle management, case management, operational workflows, reporting and analytics, integrations, and future automation.

Prioritise what matters

Using Airfocus, I managed a living backlog that balanced strategic initiatives, operational improvements, technical debt, stakeholder requests, and implementation dependencies.

• Customer impact
• Operational value
• Strategic alignment
• Implementation effort
• Technical complexity
• Delivery risk

Translate strategy into delivery

I used Jira, Airfocus, and Miro to connect long-term outcomes to day-to-day execution. Work was structured through Initiatives, Epics, User Stories, Tasks, and Subtasks so every delivery item could be traced back to a business objective.

• Customer Lifecycle Management
• Data Migration
• Workflow Automation
• Reporting and Analytics
• Platform Integrations
• Case Management
• Operational Support Processes

Write requirements that teams could build with confidence

A lot of the business logic lived in tacit operational knowledge, not in documentation. I translated that into PRDs, process maps, user stories, and Given/When/Then acceptance criteria so implementation teams could move with less ambiguity and lower delivery risk.

Keep people aligned while the system evolves

Regular roadmap reviews, backlog refinement, sprint planning, workshops, and implementation checkpoints kept stakeholders engaged and assumptions visible. Those sessions became decision-making tools, not status meetings.

Design workflows for scale

Where processes existed only because of historical system limitations, I redesigned them instead of copying them into Salesforce. That helped reduce complexity before it became embedded in the new platform.

Build the data model around the business

The Salesforce data architecture covered object relationships, custom objects, fields, layouts, validation rules, and reporting structures. A large part of the work was making sure critical operational information could be represented clearly and trusted after migration.

Treat reporting as a product requirement, not a post-launch add-on

Reporting needs shaped design decisions from the start, which made it possible to launch executive dashboards and a five-level SLA framework with meaningful service metrics already built into the platform.

• First Response Time
• First Resolution Time
• Full Resolution Time
• Reopened Cases
• Contract Generation Time
• Onboarding Time
• CSAT and NPS

Design integrations for maintainability

Rather than connecting systems directly, I designed an architecture around a message broker with one-way synchronisation from the platform into Salesforce. It required more planning, but it reduced coupling, simplified rollback, and made future integrations easier to manage.

Plan migration early and optimise for data quality

Migration planning started long before go-live. We audited duplicate records, missing values, inconsistent field structures, and undocumented business rules, then introduced validation, transformation, and reconciliation steps before data entered Salesforce.

Design governance, not just permissions

I worked with stakeholders to define roles, profiles, permission sets, visibility rules, and team access structures so teams had the right level of access without creating governance risk or unnecessary complexity.

Delivery speed vs data quality

Legacy tool renewal deadlines created pressure to move quickly, but the migration analysis exposed major data issues. I chose to slow migration enough to prioritise cleansing, validation, and reconciliation before launch, which materially improved trust in the platform after go-live.

Standardisation vs operational flexibility

I avoided both extremes: preserving every historical workflow and forcing every team into a single rigid process. Core organisational processes were standardised, while genuine team-specific needs were preserved where they added real value.

Lower implementation effort vs long-term maintainability

The message-broker architecture and one-way sync model increased early implementation effort, but it reduced long-term integration risk and made the platform more resilient as the organisation grew.

External delivery support vs internal capability

The implementation partner accelerated delivery, but I intentionally used documentation, collaborative sessions, and close engineering involvement to build internal understanding at the same time. That investment later supported the creation of a dedicated Salesforce Engineering team.

Go-live vs adoption

Training was treated as part of the product, not a handoff activity. Playbooks, process guides, role-specific training, post-launch support, and continuous improvement were all necessary to make the operating-model shift stick.