Ndosi Kamagaye | Executive Recruitment

1. About the Customer

Ndosi KaMagaye Search Partners is a South African executive recruitment and headhunting firm specialising in board-level, executive, and senior management appointments.

The company has extensive experience within the financial services sector, including asset management, wealth management, unit trusts, banking, and insurance. It also provides recruitment services to organisations in the public sector, non-governmental organisations, academia, technology, and other professional industries.

Ndosi KaMagaye operates within the small and medium-sized business market segment. Its work requires the management of highly confidential candidate information, client requirements, executive search assignments, CVs, interview records, placement documentation, and commercial information.

The company differentiates itself through a client-focused executive search methodology and access to a broad professional network used to identify high-calibre leadership talent.

Because its services depend heavily on information management, collaboration, client relationship management, and the secure handling of candidate records, the company required a centralised digital platform that could support its operations as it continued to grow.

2. Key Business Challenge

Ndosi KaMagaye did not have a centralised system for managing its candidate records, business documents, customer relationships, executive search assignments, sales opportunities, and financial information.

CVs, résumés, client briefs, project documents, and placement records were distributed across individual email accounts, spreadsheets, and local computer folders. This made it difficult for team members to locate information quickly and increased the likelihood of document duplication, outdated versions, inconsistent record keeping, and information being stored in locations that were not accessible to the wider team.

The company also needed a customer relationship management system that reflected its specific executive recruitment process. Generic spreadsheets and basic contact management tools did not provide a clear view of where each prospect, client engagement, or executive search assignment was within the sales and delivery lifecycle.

Management could not easily obtain a consolidated view of:

• Potential client leads.
• Proposals and recruitment mandates.
• Active executive search assignments.
• Candidate sourcing and shortlisting.
• Client interviews.
• Completed placements.
• Outstanding client follow-ups.
• Invoices and payment information.

The fragmented operating environment also affected collaboration. Consultants needed to share candidate profiles, project documents, client updates, and recruitment progress, but there was no reliable shared workspace with consistent version control and role-based access.

Without intervention, the company faced immediate risks that included missed client follow-ups, misplaced candidate records, duplicated information, inconsistent document versions, limited management visibility, and excessive time spent searching for information.

The longer-term risk was that the company’s operating model would become increasingly difficult to manage as the number of candidates, clients, employees, and executive search assignments increased.

The lack of standardised workflows and centralised information could ultimately have constrained growth, reduced service quality, increased administrative costs, and exposed confidential candidate and client information to inappropriate access.

3. Goals and Objectives

The primary goal of the engagement was to provide Ndosi KaMagaye with a secure, integrated, and scalable business management platform that could serve as the central operating system for its executive search business.

The customer’s business objectives were to:

• Establish a single source of truth for candidate, client, sales, project, document, and financial information.
• Replace disconnected spreadsheets, email attachments, and local computer folders with structured digital workflows.
• Configure a CRM pipeline that reflected the company’s executive recruitment methodology.
• Improve visibility into potential clients, proposals, active mandates, candidate shortlists, interviews, and completed placements.
• Improve collaboration between consultants, researchers, management, finance personnel, and external service providers.
• Reduce the time required to locate candidate CVs, client briefs, project records, and other business documents.
• Standardise the collection of candidate information.
• Streamline invoice generation, payment tracking, and financial reporting.
• Provide management with timely operational and financial information.
• Support future growth without requiring the customer to maintain its own technology infrastructure.

The technical objectives were to:

• Provide secure browser-based access to the platform.
• Centralise document storage within a cloud-based repository.
• Protect sensitive information through role-based access control.
• Allow authorised employees to access information from different locations and devices.
• Separate application processing, data storage, document storage, caching, and content delivery responsibilities.
• Provide a production-grade AWS environment capable of scaling as customer usage increased.
• Implement monitoring, logging, backup, security, and operational support controls.
• Reduce the customer’s dependence on locally installed applications and office-based infrastructure.

4. Designation Definition Fit

This customer reference aligns with the AWS Small and Medium Business Competency within the SaaS Solutions category.

Ndosi KaMagaye is an SMB customer that required an affordable, scalable, and easy-to-use software platform without the complexity of implementing and maintaining several separate enterprise applications.

The SkhokhoAI implementation supports several business functions that fall within the scope of SMB-focused SaaS solutions, including:

• Customer relationship management.
• Document management.
• Resource and project management.
• Financial administration.
• Accounting and invoicing.
• Data collection.
• Management reporting.
• Team collaboration.
• Role-based information access.

The CRM module was configured to support the customer’s executive search process. The configured pipeline included stages such as:

• Lead identified.
• Client needs analysis.
• Talent sourcing.
• Candidate shortlist.
• Client interview.
• Placement and closure.

The document management functionality provided a structured repository for CVs, client briefs, reference documents, recruitment project records, and placement information.

Skhokho Tables provided configurable forms and data structures for collecting candidate information and uploaded CVs. This created a central candidate database that could be searched and filtered when new executive search assignments were received.

The finance functionality enabled the customer to generate invoices, import bank statements, categorise transactions, monitor income and expenses, and produce management reports.

The solution is therefore a strong fit for the designation because it demonstrates how an AWS-hosted SaaS platform can provide an SMB customer with integrated business management capabilities without requiring the customer to employ a dedicated infrastructure or cloud operations team.

5. Technical Solution

Tati Software implemented SkhokhoAI as the customer’s central business management platform.

SkhokhoAI is a multi-functional SaaS platform that integrates CRM, document management, projects, forms, financial management, accounting, invoicing, human resources, reporting, and collaboration within a single application.

The customer implementation included:

• A customised CRM sales and executive search pipeline.
• Centralised candidate and project document storage.
• Custom forms for candidate and CV submissions.
• Candidate information tables.
• Invoice generation.
• Bank statement imports.
• Transaction categorisation.
• Financial reporting.
• User administration.
• Role-based access control.
• Shared access to client, candidate, project, and financial information.

Architecture Diagram Reference

As illustrated in the accompanying architecture diagram, users access the SkhokhoAI platform through the public application domain.

Amazon Route 53 provides DNS resolution for the application domain. Amazon CloudFront provides content delivery and caching for static application content.

Application requests are routed through an Application Load Balancer to containerised application services running on Amazon Elastic Container Service with AWS Fargate.

The SkhokhoAI web application and API are implemented using Python and Django. The application layer handles user authentication, business rules, organisation separation, permissions, CRM processing, document metadata, financial processing, and reporting.

PostgreSQL provides the relational data layer for:

• Organisations.
• Users.
• Roles and permissions.
• CRM records.
• Candidate records.
• Client records.
• Project information.
• Financial transactions.
• Invoices.
• Configuration information.
• Reporting data.

Redis provides a high-performance caching and temporary data layer. It is used for activities such as application caching, session support, temporary processing data, and background task coordination.

Amazon S3 stores uploaded CVs, candidate documents, client files, generated reports, attachments, and other unstructured business content.

The application runs within an Amazon Virtual Private Cloud. Public and private subnets separate internet-facing services from application and data components.

AWS Identity and Access Management controls permissions between AWS services and administrative users. Security groups restrict traffic between the load balancer, application services, database layer, cache layer, and other infrastructure components.

Amazon CloudWatch provides centralised application logs, infrastructure metrics, health monitoring, and operational visibility.

Amazon Route 53

Amazon Route 53 was selected to provide DNS resolution for the production application domain.

It integrates directly with AWS services and supports alias records for AWS resources. It also allows DNS administration to remain within the same AWS environment as the production workload.

A third-party DNS-only service was considered. It was not selected because it would introduce another administration platform and would provide less direct integration with the AWS-hosted architecture.

Amazon CloudFront

Amazon CloudFront was selected to deliver static content and cache frequently requested application resources.

CloudFront reduces repeated requests to the application origin, improves content delivery performance, and provides a consistent HTTPS delivery layer.

Serving all static content directly through the application service was considered but rejected because it would increase load on the application containers.

Serving content directly from an Amazon S3 origin without CloudFront was also considered. This option was not selected because CloudFront provides edge caching, HTTPS delivery, and improved performance for users accessing the platform from different locations.

Amazon S3

Amazon S3 was selected to store CVs, candidate documents, client files, project attachments, exported reports, and application assets.

The volume of these documents can increase independently from the application workload. Amazon S3 provides scalable object storage without requiring Tati Software or the customer to provision and maintain file servers or storage volumes.

Storing uploaded documents directly on the application containers was rejected because ECS tasks can be replaced during deployments, scaling events, or infrastructure recovery.

Amazon Elastic Block Store was not selected as the primary document repository because it would couple documents to individual compute resources.

Amazon Elastic File System was considered but was not required because the application uses object-based document storage rather than a shared POSIX file system.

Amazon ECS with AWS Fargate

Amazon ECS with AWS Fargate was selected to run the containerised Django application and API services.

Fargate removes the requirement to provision, patch, monitor, and replace underlying container host instances. This reduces infrastructure administration and supports the operational model required for an SMB-focused SaaS platform.

Self-managed Amazon EC2 instances were considered. They were not selected because Tati Software would have needed to manage operating systems, instance patching, host capacity, and container placement.

Amazon Elastic Kubernetes Service was considered but rejected because the additional Kubernetes control, administration, and operational complexity was not justified by the workload.

AWS Lambda was considered for individual event-driven processes but was not selected as the primary application runtime because SkhokhoAI contains sustained web, API, reporting, and background-processing workloads that are better suited to continuously available containers.

Application Load Balancer

The Application Load Balancer distributes incoming HTTPS requests across healthy ECS tasks.

It provides health checks, TLS termination, HTTP routing, and controlled access to the application containers.

A Network Load Balancer was considered but was not selected because the platform requires Layer 7 HTTP and HTTPS routing rather than Layer 4 network forwarding.

Amazon API Gateway was considered for API-specific traffic but was not selected as the primary application entry point because SkhokhoAI includes a complete web application in addition to its APIs.

Amazon VPC

Amazon VPC provides network isolation for the production environment.

Internet-facing components are separated from application and data components through public and private subnets.

The Application Load Balancer can accept approved internet traffic, while the application, database, and cache components remain within restricted network segments.

A flat architecture in which all resources were publicly accessible was rejected because it would unnecessarily increase the attack surface of the production environment.

NAT Gateway

A NAT Gateway enables workloads in private subnets to access approved internet services without allowing unsolicited inbound connections.

This enables private application workloads to obtain required external resources while remaining inaccessible directly from the public internet.

Placing application containers in public subnets was rejected because the containers do not need to accept direct public traffic.

S3 Gateway VPC Endpoint

An S3 Gateway VPC Endpoint enables workloads within the VPC to communicate with Amazon S3 without routing that traffic through the public internet or NAT Gateway.

This reduces unnecessary NAT processing costs and provides a more direct route between the application and Amazon S3.

Routing all S3 traffic through the NAT Gateway was considered but rejected because it would introduce avoidable network costs and complexity.

PostgreSQL

PostgreSQL was selected because SkhokhoAI processes highly relational business information.

CRM records are related to organisations, contacts, opportunities, projects, candidate records, documents, invoices, transactions, employees, and user permissions.

The solution also requires transactional consistency, relational constraints, structured reporting, and reliable processing of financial information.

Amazon DynamoDB was considered but was not selected as the primary database because the workload contains complex relationships and reporting requirements that are well suited to a relational database.

Separate databases for every application module were considered but rejected at the current platform scale because they would increase integration, reporting, and operational complexity.

Redis

Redis was selected to provide caching, temporary data storage, session support, and background task coordination.

Redis reduces repeated reads against the relational database and improves the responsiveness of frequently accessed application functions.

Using PostgreSQL for all cache and session operations was considered but rejected because it would place unnecessary workload on the transactional database.

Storing cache information in the memory of individual application containers was also rejected because the information would not be shared consistently across multiple ECS tasks.

Amazon CloudWatch

Amazon CloudWatch provides centralised logging and monitoring for the application and its supporting infrastructure.

Application and container logs can be reviewed from one operational interface. Metrics and alarms can be used to identify service interruptions, application errors, capacity constraints, and abnormal behaviour.

Local container logs were rejected as the primary monitoring approach because containers may be replaced during deployment or scaling. Locally retained logs would also not provide a consolidated view of the production environment.

AWS Identity and Access Management

AWS Identity and Access Management provides controlled access to AWS resources.

IAM roles are assigned to application workloads and administrators according to the principle of least privilege.

Long-lived shared AWS access keys were rejected because they increase credential management, audit, and security risks.

Integration Between Components

The major integration flow is as follows:

1. A user accesses the SkhokhoAI application through a supported web browser.
2. Amazon Route 53 resolves the application domain.
3. Amazon CloudFront serves cached application content and forwards relevant requests to the application origin.
4. The Application Load Balancer routes application traffic to healthy ECS Fargate tasks.
5. The Django web application or API authenticates the user.
6. The application determines the user’s organisation, role, and permitted functions.
7. Business information is read from or written to PostgreSQL.
8. Redis supports session, caching, and temporary processing requirements.
9. Uploaded CVs and business documents are stored in Amazon S3.
10. Document metadata and the relationship between documents and business records are stored within PostgreSQL.
11. CRM records can be associated with client contacts, candidate records, documents, projects, invoices, and financial transactions.
12. Imported bank transactions are processed and presented to authorised users for categorisation.
13. Financial reports are generated from the customer’s processed transaction and invoice data.
14. Application logs and operational metrics are sent to Amazon CloudWatch.

6. Solution Optimality

Several solution approaches were considered before SkhokhoAI was selected.

Separate Point Solutions

The customer could have implemented separate applications for CRM, document storage, candidate tracking, project management, accounting, forms, and reporting.

This approach was rejected because it would have introduced several subscriptions, different login credentials, duplicate information, inconsistent permissions, and additional integration requirements.

It would also have recreated the fragmentation that the customer was trying to eliminate.

Custom Recruitment Platform

A completely bespoke recruitment or applicant tracking system could have been developed specifically for Ndosi KaMagaye.

This approach was not selected because the cost, development period, testing requirements, security responsibilities, and ongoing maintenance obligations would have been disproportionate for an SMB customer.

A recruitment-only system would also not necessarily have provided the customer with integrated invoicing, financial management, document management, project management, and reporting capabilities.

Generic CRM Platform

A generic CRM product could have been configured for lead tracking.

This option was rejected because it would not have addressed the full customer requirement. The customer also required document management, candidate data collection, accounting, bank statement imports, role-based access, project information, and management reporting.

Additional systems and integrations would therefore still have been required.

On-Premises Software

The solution could have been installed on a physical server within the customer’s office.

This approach was rejected because it would have required the customer to manage hardware, operating systems, backups, security, networking, remote access, and disaster recovery.

It would also have required capital expenditure and would have been more difficult to scale.

Selected Approach

SkhokhoAI was selected because it provided the required business functions through one integrated SaaS platform.

The solution enabled Tati Software to configure the platform around the customer’s recruitment process without developing a new application from the beginning.

The customer received:

• A configurable CRM.
• Central document storage.
• Candidate data collection.
• Financial administration.
• Management reporting.
• Controlled user access.
• Secure remote availability.
• Ongoing platform improvements.
• A scalable AWS-hosted production environment.

This approach maximised business value while limiting implementation complexity, capital expenditure, infrastructure management, duplicated data, and the number of software products the customer needed to operate.

9. Key Performance Indicators

The following KPIs summarise the measurable improvements demonstrated during the engagement. Final values should be validated and approved by the customer before the competency submission is completed.

Measurement methodology

Baseline values were established by reviewing the systems, tools and reporting cycle used before implementation. Actual results were measured by reviewing the production workflows adopted after onboarding and confirming the platform used to perform each activity.

10. Continuous Improvement

Role-Based Access Configuration

One of the main implementation challenges involved the allocation of user permissions.

The person who initially created the customer’s SkhokhoAI account was not the person responsible for financial administration.

The original account creator initially had broad administrative permissions, while the finance manager did not have all the access required to perform finance-related responsibilities.

The issue was resolved by adjusting the platform’s role-based access configuration and enabling the organisation’s authorised superuser to allocate account management responsibilities to the appropriate employee.

Future implementations will include a formal role-mapping process before users are configured.

The role-mapping process will identify:

• Organisation owners.
• Account administrators.
• Finance administrators.
• Operational managers.
• Standard employees.
• External accountants.
• Restricted users.
• Users authorised to approve financial activities.

A permissions matrix will be reviewed with the customer before the production account is activated.

Data Migration and Data Quality

The customer’s information was initially distributed across emails, spreadsheets, and local folders.

This created challenges relating to:

• Duplicate records.
• Inconsistent document names.
• Missing information.
• Different spreadsheet formats.
• Unclear document ownership.
• Unstructured folders.
• Outdated files.

Future customer implementations will include a structured data readiness assessment before migration.

Customers will be provided with standard templates for:

• Contacts.
• Leads.
• Opportunities.
• Candidate records.
• Document metadata.
• Project information.
• Financial information.

Data will be reviewed for completeness, duplicates, and formatting issues before it is migrated into the production environment.

User Adoption

SkhokhoAI includes several integrated modules. Introducing every module simultaneously could have overwhelmed users and reduced adoption.

The risk was managed by dividing the implementation into focused onboarding sessions.

The initial session concentrated on the CRM pipeline, document structure, and candidate information forms.

The next session concentrated on practical CRM usage, document collaboration, invoicing, bank statement imports, and management reporting.

The final session addressed subscription activation, user access, and permissions.

Future implementations will continue to use phased onboarding.

Each phase will include:

• Clearly defined business processes.
• Practical customer-specific exercises.
• User acceptance criteria.
• Assigned customer process owners.
• Training records.
• Post-training support.
• Formal production readiness confirmation.

KPI Baseline Collection

The customer's previous environment did not consistently track the metrics below through a formal measurement process. The table sets out estimated baseline values (before Skhokho) against measured results (after Skhokho), based on the onboarding assessment and production workflow review.

These values should be validated and formally approved by the customer before use in a competency submission. Future implementations will establish KPI baselines during the discovery phase, documenting the baseline value, measurement period, data source, improvement target, responsible customer owner, measurement frequency, actual post-implementation result and customer approval for each KPI.

Ongoing Customer Support

Tati Software continued to support the customer after production onboarding through scheduled follow-up sessions.

These sessions were used to:

• Review platform adoption.
• Answer user questions.
• Adjust configuration.
• Review permissions.
• Introduce relevant platform improvements.
• Identify additional processes that could be digitised.
• Support changes in the customer’s organisation.

The lessons from the implementation have been incorporated into improved onboarding, data migration, access configuration, KPI measurement, and customer success processes for future customers.