Mah Quests Enterprises | ICT & Innovation

1. About the Customer

Mah Quests Enterprises (Pty) Ltd is a South African, black-owned and women-managed information and communications technology company founded in 2012.

The company delivers enterprise software, cloud solutions, technology advisory services, and digital innovation programmes. Mah Quests is recognised for its expertise in Java programming, cloud technologies, and frugal innovation: the design of cost-effective and scalable technology solutions that address practical African business and social challenges.

Mah Quests operates within the small and medium-sized business market segment. Its business model depends on developing partnerships, identifying new technology opportunities, running marketing and outreach campaigns, managing prospective customers, and converting qualified opportunities into projects.

As the company expanded its outreach, partnership network, and innovation initiatives, the volume of contacts and potential opportunities entering its sales ecosystem increased. These contacts originated from multiple channels, including:

• Marketing campaigns.
• Referrals.
• Website forms.
• Direct engagements.
• Partnership initiatives.
• Existing databases and spreadsheets.

The company therefore required a structured and scalable customer relationship management platform that could improve data quality, standardise lead capture, enforce qualification criteria, and provide management with timely visibility into the sales funnel.

2. Key Business Challenge

Mah Quests experienced operational challenges relating to bulk contact imports, lead data quality, lead qualification, sales activity tracking, and management visibility.

The company regularly conducts high-volume outreach and marketing campaigns. However, contact information received from legacy databases and spreadsheets did not consistently follow the same structure.

Before information could be uploaded into a CRM or used for a campaign, employees frequently needed to:

• Correct inconsistent field names.
• Reformat spreadsheet columns.
• identify duplicate contacts.
• Correct malformed email addresses or telephone numbers.
• Fill in missing information.
• Standardise campaign and source information.
• Re-segment leads after import.

This manual preparation reduced campaign efficiency and created a risk of introducing further errors during data correction.

Mah Quests also received leads through several channels. Without a controlled lead capture structure, the quality and completeness of information varied depending on how and where a lead entered the business.

Sales employees often had to correct, classify, or supplement lead information after the record had already been created. This limited the reliability of reports and made segmentation dependent on manual oversight.

A further challenge was the absence of explicit conversion logic in the sales funnel. The transition from a prospect to a qualified lead was not governed by consistent system rules.

Opportunities could therefore be marked as qualified even when essential information had not been confirmed, such as:

• The identity of the decision-maker.
• The availability of funding or an approved budget.
• The customer’s need or intended project.
• The expected opportunity value.
• The expected implementation timeline.
• The urgency of the opportunity.
• The next required sales activity.

This created delayed and inconsistent funnel visibility. Management could not immediately determine how many prospects were genuinely qualified, which opportunities required attention, or where conversion delays were occurring.

Without intervention, Mah Quests faced immediate business risks that included:

• Campaign delays caused by manual spreadsheet preparation.
• Duplicate, malformed, or incomplete customer records.
• Inaccurate lead segmentation.
• Unreliable sales reports.
• Inconsistent lead qualification.
• Missed follow-ups.
• Sales opportunities remaining inactive without management visibility.
• Employees working from different versions of customer information.

The longer-term risk was the accumulation of data debt. As the company’s marketing campaigns, partnerships, and opportunity pipeline grew, inconsistent data and informal qualification practices would have become increasingly expensive to correct.

The lack of structured data and measurable conversion events could also have weakened sales forecasting, reduced management confidence in CRM reports, and limited the company’s ability to scale its outreach activities efficiently.

3. Goals and Objectives

The primary goal of the engagement was to implement SkhokhoAI as a clean, structured, and scalable operating platform for Mah Quests’ lead and opportunity management processes.

The customer’s business objectives were to:

• Establish a central CRM for prospects, leads, contacts, opportunities, and sales activities.
• Standardise the structure used for bulk contact and lead uploads.
• Reduce manual spreadsheet preparation before marketing campaigns.
• Prevent duplicate, malformed, and incomplete records from entering the CRM.
• Capture the source of every lead at the point of entry.
• Ensure that required customer and opportunity information is collected consistently.
• Configure a sales pipeline that reflected Mah Quests’ actual sales process.
• Define explicit criteria for converting prospects into qualified leads.
• Improve the prioritisation of high-potential opportunities.
• Provide management with real-time sales funnel visibility.
• Improve follow-up discipline and accountability.
• Enable reliable segmentation and reporting.
• Create a foundation for future integrations and controlled automation.

The technical objectives were to:

• Implement a browser-based, cloud-hosted CRM.
• Configure mandatory fields and standardised data structures.
• Support validated CSV imports for bulk campaign data.
• Configure lead source tagging.
• Implement configurable lead scoring.
• Record calls, meetings, emails, notes, and follow-up activities against each lead.
• Timestamp sales stage transitions for analysis.
• Provide dashboards and reports based on structured CRM information.
• Protect customer information through organisation-level access controls and role-based permissions.
• Provide a production-grade AWS environment that could scale as data volumes and user activity increased.
• Implement monitoring, logging, backup, security, and operational support controls.

4. Designation Definition Fit

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

Mah Quests is an SMB customer that required a cost-effective SaaS platform capable of improving customer relationship management, data governance, sales operations, activity tracking, and management reporting.

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

• Customer relationship management.
• Lead and opportunity management.
• Customer data management.
• Marketing data preparation.
• Sales activity tracking.
• Workflow standardisation.
• Reporting and business intelligence.
• Team collaboration.
• Role-based information access.
• Resource and task management.

The implementation is a strong fit for the designation because Mah Quests required enterprise-grade operational control without the cost and complexity of implementing a large enterprise CRM or maintaining its own infrastructure.

The configured solution delivered the following substantive SaaS capabilities:

Structured Bulk Data Management

SkhokhoAI was configured with a standard CSV upload schema for campaign contacts and leads.

The schema defined:

• Required fields.
• Consistent column names.
• Accepted field formats.
• Source information.
• Duplicate handling.
• Pre-upload validation requirements.

This provided Mah Quests with a repeatable process for importing large campaign datasets without recreating the spreadsheet-cleaning process for every campaign.

Controlled Lead Capture

Skhokho CRM and Skhokho Tables were configured with controlled lead intake fields.

Each new contact or lead is categorised according to its source and captured with the information required for segmentation, reporting, and sales follow-up.

Lead Qualification and Scoring

The CRM was configured with qualification criteria and scoring factors relevant to Mah Quests’ sales process.

These factors included:

• Decision-maker identification.
• Confirmed funding or budget availability.
• Opportunity urgency.
• Expected timeline.
• Opportunity value.
• Completeness of required information.

This enabled the company to prioritise opportunities based on defined business criteria rather than subjective judgement alone.

Sales Funnel Visibility

The sales pipeline was tailored to the customer’s workflow.

Stage changes are recorded as measurable events, enabling management to review:

• Prospect volumes.
• Qualified lead volumes.
• Opportunities under evaluation.
• Proposals in progress.
• Deals in negotiation.
• Inactive or delayed opportunities.
• Conversion patterns.

Activity Tracking

Calls, meetings, emails, notes, and follow-up actions are recorded against each lead.

This provides a central activity history and supports improved accountability between sales and account management employees.

The implementation therefore demonstrates how an AWS-hosted SaaS solution can help an SMB establish data governance, improve sales execution, and obtain reliable operational insight without building and maintaining a custom CRM platform.

5. Technical Solution

Tati Software implemented SkhokhoAI as Mah Quests’ central CRM and lead data management platform.

SkhokhoAI is a multi-functional SaaS platform that integrates CRM, custom data tables, forms, project management, document management, financial management, human resources, reporting, collaboration, and business intelligence within one application.

The Mah Quests implementation focused on:

• Standardised contact and lead imports.
• Controlled lead capture.
• Lead source tagging.
• Sales pipeline configuration.
• Lead qualification.
• Lead scoring.
• Sales activity logging.
• Follow-up tracking.
• Funnel analytics.
• CRM reporting.
• Data export.
• User access management.
• Future integration readiness.

Architecture Diagram Reference

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

Amazon Route 53 provides DNS resolution for the application domain.

Amazon CloudFront distributes static application content and reduces repeated requests to the origin infrastructure.

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

The web application and API are implemented using Python and Django. The application layer performs:

• User authentication.
• Organisation separation.
• Role and permission enforcement.
• Contact and lead processing.
• CSV import validation.
• Duplicate checks.
• Lead scoring.
• Sales stage processing.
• Activity logging.
• Reporting.
• Export processing.
• Business rule enforcement.

PostgreSQL provides the relational data layer for organisations, users, contacts, leads, opportunities, activities, stage transitions, scoring information, custom fields, reports, and platform configuration.

Redis provides application caching, session support, temporary processing data, and background workload coordination.

Amazon S3 stores uploaded CSV files, exported reports, attachments, and other unstructured content associated with the customer’s CRM records.

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 network communication between the Application Load Balancer, application services, database layer, cache layer, and supporting infrastructure.

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

Amazon Route 53

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

Route 53 integrates directly with AWS-hosted services and supports alias records for AWS resources. It allows the application domain and the supporting production infrastructure to be administered within the same AWS environment.

A third-party DNS-only provider was considered but was not selected because it would introduce an additional administration platform and reduce direct integration with the AWS environment.

Amazon CloudFront

Amazon CloudFront was selected to deliver static application content through distributed edge locations.

CloudFront improves delivery performance, reduces repeated origin requests, and supports secure HTTPS content delivery.

Serving all static assets directly from the Django application was considered but rejected because it would consume application compute resources that should remain available for CRM processing, validation, reporting, and API requests.

Serving assets directly from an Amazon S3 origin without CloudFront was also considered. This approach was not selected because CloudFront provides edge caching, controlled origin access, and improved delivery performance.

Amazon S3

Amazon S3 was selected to store:

• Uploaded CSV files.
• Data import files.
• Exported lead reports.
• Generated reports.
• CRM attachments.
• Supporting documents.
• Application assets.

Amazon S3 provides scalable object storage without requiring Tati Software or Mah Quests to provision and maintain a file server.

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

Amazon Elastic Block Store was not selected as the primary file repository because it would couple files to specific compute resources.

Amazon Elastic File System was considered but was not required because the application uses object-based file access 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, and maintain container host instances. Tati Software can deploy and scale the application without managing the underlying server fleet.

Self-managed Amazon EC2 instances were considered but were not selected because they would require operating system maintenance, patching, capacity planning, and host-level monitoring.

Amazon Elastic Kubernetes Service was considered but rejected because the operational complexity of Kubernetes was not justified by the current workload.

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

Application Load Balancer

The Application Load Balancer distributes HTTPS traffic across healthy ECS Fargate tasks.

It provides:

• TLS termination.
• Application health checks.
• HTTP and HTTPS routing.
• Controlled public access.
• Distribution of requests across multiple application tasks.

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

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

Amazon VPC

Amazon VPC provides network isolation for the production environment.

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

The Application Load Balancer accepts authorised public traffic, while the application, database, and caching components are protected within restricted network segments.

A flat public network was rejected because application and data services do not require direct internet exposure.

NAT Gateway

A NAT Gateway enables private application workloads to access approved external services without accepting unsolicited inbound connections.

This preserves the private placement of application components while supporting approved outbound dependencies.

Placing the application containers in public subnets was rejected because external users should access the platform only through the controlled load-balancing layer.

S3 Gateway VPC Endpoint

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

This provides a more direct AWS network path and avoids unnecessary NAT data processing for S3 communication.

Routing all S3 traffic through the NAT Gateway was considered but rejected because it would create avoidable network costs and an unnecessary processing path.

PostgreSQL

PostgreSQL was selected because CRM information is highly relational.

The platform must maintain relationships between:

• Organisations.
• Users.
• Contacts.
• Prospects.
• Qualified leads.
• Opportunities.
• Activities.
• Lead sources.
• Scores.
• Sales stages.
• Stage transitions.
• Custom fields.
• Attachments.
• Reports.

The solution also requires transactional consistency, referential integrity, structured queries, and reliable reporting.

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

Separate databases for each CRM function were considered but rejected because they would increase integration, reporting, and operational complexity without providing sufficient benefit at the current workload scale.

Redis

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

Redis improves application responsiveness and reduces repeated reads against the PostgreSQL database.

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

Storing cache information within individual application containers was also rejected because the information would not remain consistent across multiple ECS tasks.

Amazon CloudWatch

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

CloudWatch allows the operations team to identify:

• Application errors.
• Failed imports.
• Processing delays.
• Container health problems.
• Resource constraints.
• Abnormal request patterns.
• Availability incidents.

Local container logs were rejected as the primary logging approach because containers can be replaced and local logs would not provide a durable, consolidated operational record.

AWS Identity and Access Management

AWS Identity and Access Management controls access to AWS resources.

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

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

Integration Between Components

The main integration flow is as follows:

1. A user accesses SkhokhoAI through a supported web browser.
2. Amazon Route 53 resolves the production application domain.
3. Amazon CloudFront serves cached static application content and forwards relevant requests to the application origin.
4. The Application Load Balancer distributes dynamic requests to healthy ECS Fargate tasks.
5. The Django application authenticates the user.
6. The application determines the user’s organisation, role, and permitted CRM functions.
7. Contact, lead, opportunity, activity, and scoring data is read from or written to PostgreSQL.
8. Redis supports sessions, caching, temporary data, and background processing.
9. CSV files, exports, and attachments are stored in Amazon S3.
10. A user uploads a campaign CSV file through the application.
11. The application validates the file structure, required fields, and record formats.
12. Duplicate or invalid records are identified before accepted records are committed to the CRM database.
13. Each accepted contact or lead is associated with a source category.
14. Sales employees record calls, emails, meetings, notes, and follow-up activities against the appropriate lead.
15. The application recalculates lead scores when relevant qualification information changes.
16. A prospect can be converted into a qualified lead only when the configured business criteria have been satisfied.
17. Stage transitions are timestamped and retained for reporting.
18. Management dashboards use the structured CRM information to display funnel volumes, lead status, opportunity movement, and follow-up requirements.
19. Operational logs and infrastructure metrics are sent to Amazon CloudWatch.

External Integration Approach

Mah Quests identified Microsoft Outlook, calendars, Trello, and business intelligence tools as important components of its broader operating environment.

The production implementation established SkhokhoAI as the system of record for CRM and sales information.

External integrations were assessed as controlled future enhancements. The proposed approach was to use documented APIs or an approved integration platform so that information could be exchanged without creating unmanaged point-to-point connections.

Potential integration use cases included:

• Synchronising approved calendar events.
• Recording selected email or meeting activity.
• Creating project tasks after an opportunity reaches an approved stage.
• Sending CRM activity data to business intelligence dashboards.
• Generating follow-up reminders for inactive leads.

The proposed AI-assisted scheduling and follow-up concept was not treated as an uncontrolled production automation.

The agreed design principle was that the system could prepare recommendations, reminders, draft follow-up messages, or proposed meeting invitations, while an authorised employee would review and approve customer-facing actions.

This human-in-the-loop approach was selected to preserve customer relationship quality and reduce the risk of incorrect communications or scheduling actions.

6. Solution Optimality

Several alternatives were considered before SkhokhoAI was selected.

Continued Spreadsheet-Based Management

Mah Quests could have continued managing campaign contacts and opportunities through spreadsheets.

This approach was rejected because spreadsheets did not enforce required fields, source tagging, qualification criteria, access control, activity history, or controlled stage transitions.

The approach would also have required repeated manual preparation before every campaign and would have allowed data quality to deteriorate as record volumes increased.

Separate Marketing, CRM, and Reporting Products

The customer could have implemented separate products for campaign data preparation, CRM, activity tracking, reporting, and business intelligence.

This approach was rejected because it would have created multiple subscriptions, separate user accounts, duplicate records, integration requirements, and inconsistent access controls.

It would also have made it more difficult to identify which system contained the authoritative version of each customer or opportunity record.

Large Enterprise CRM Platform

A large enterprise CRM platform could have provided extensive functionality.

This option was not selected because the licensing structure, implementation effort, administrative burden, and configuration complexity would have been disproportionate for an SMB customer.

Mah Quests required an adaptable platform that could be configured quickly and expanded progressively without a large implementation programme.

Fully Custom CRM Development

Tati Software could have developed a bespoke CRM specifically for Mah Quests.

This approach was rejected because it would have required a longer development lifecycle, greater capital investment, dedicated testing, security review, maintenance, and ongoing feature development.

A bespoke system would also have duplicated functionality already available within SkhokhoAI.

Uncontrolled End-to-End Automation

The customer considered automated follow-ups and meeting scheduling through an AI-driven assistant.

Fully autonomous customer communication was not selected for the initial implementation.

The risk of sending an inappropriate message, using incomplete context, or creating an incorrect meeting required a controlled approach.

The preferred future design uses human review and approval before customer-facing actions are completed.

Selected Approach

SkhokhoAI was selected because it offered the best balance of:

• Functional coverage.
• Implementation speed.
• Data governance.
• Configurability.
• Affordability.
• Operational simplicity.
• Security.
• Scalability.
• Future integration capability.

The solution allowed Tati Software to configure a structured CRM process without developing a new application from the beginning.

The customer received:

• A central CRM.
• Standardised bulk data imports.
• Controlled lead intake.
• Mandatory source tagging.
• Lead qualification rules.
• Lead scoring.
• Sales activity histories.
• Real-time funnel visibility.
• Follow-up tracking.
• Reporting.
• Secure browser-based access.
• A scalable AWS-hosted environment.

This approach maximised business value while minimising implementation cost, infrastructure administration, duplicate information, and unnecessary system complexity.

9. Key Performance Indicators

The implementation was evaluated using system-enforced data quality and sales process controls. The KPIs below focus on measurable changes between the previous uncontrolled process and the configured production workflow.

Measurement methodology

Baselines were established during discovery by reviewing the previous lead capture, qualification and import processes and confirming that no system-enforced rule existed. Results were measured through configuration review and user acceptance testing of the production workflow.

Management visibility and employee accountability also improved. Opportunity volumes and movement can now be reviewed directly through the configured funnel, and sales employees record calls, emails, meetings, notes and follow-up activities against each lead, creating a shared interaction history. The final KPI values and validation evidence should be reviewed and approved by Mah Quests before the competency submission is completed.

10. Continuous Improvement

Bulk Lead Import Capability

During onboarding, Mah Quests identified the need to migrate and process large volumes of legacy lead information.

The available contact import process supported initial onboarding, but the customer required a more refined bulk lead workflow with stronger validation, qualification fields, and campaign context.

The implementation therefore required an interim process while the enhanced lead import capability was being developed and configured.

For future implementations, Tati Software will assess bulk migration requirements during discovery and document:

• Expected record volumes.
• Required lead fields.
• Source data systems.
• Duplicate handling rules.
• Validation rules.
• Rejection and correction procedures.
• Migration ownership.
• User acceptance criteria.
• Rollback requirements.

Representative source files will be tested before production migration begins.

Legacy Data Quality

Mah Quests’ existing records were stored across spreadsheets and a legacy database.

The information contained inconsistent structures and required review before migration.

This demonstrated that CRM implementation success depends not only on the destination platform but also on the quality of source information.

Future implementations will include a formal data readiness assessment.

The assessment will cover:

• Required fields.
• Missing values.
• Duplicate records.
• Invalid email addresses.
• Telephone number formats.
• Naming conventions.
• Source categories.
• Record ownership.
• Consent and retention requirements.
• Archival rules.

Customers will receive standard migration templates and data correction reports before production import.

Qualification Criteria Calibration

Lead scoring and qualification criteria must reflect genuine sales potential.

There is a risk that employees may attempt to maximise a score without improving the underlying quality of an opportunity.

During onboarding, the customer was advised that the purpose of scoring was to represent reality accurately rather than to produce the highest possible score.

Future implementations will include a qualification calibration workshop involving sales leadership and operational users.

The workshop will define:

• Mandatory qualification conditions.
• Weighted scoring factors.
• Disqualifying conditions.
• Required supporting information.
• Review responsibilities.
• Score review frequency.
• Conditions for reopening or reclassifying a lead.

Scoring outcomes will be compared with actual opportunity progression and adjusted when the model no longer reflects business reality.

Activity Logging Discipline

CRM reporting and follow-up reminders depend on employees recording calls, meetings, emails, notes, and next actions consistently.

Incomplete activity histories reduce the reliability of reminders and management reporting.

Future implementations will include:

• Required activity categories.
• Minimum activity information.
• Follow-up ownership.
• Next-action dates.
• Stale lead thresholds.
• User training.
• Periodic activity completeness reviews.
• Management dashboards for overdue follow-ups.

External Integrations

Mah Quests uses tools such as Microsoft Outlook, calendars, Trello, and business intelligence dashboards.

Integrating these systems can reduce duplicate data capture, but uncontrolled integrations could create conflicting records, duplicate activities, or inappropriate access.

Future integrations will be implemented through documented APIs or approved integration services.

Each integration will define:

• The system of record.
• The direction of data flow.
• Authentication requirements.
• Permitted fields.
• Synchronisation frequency.
• Error handling.
• Duplicate prevention.
• Audit logging.
• Data retention.
• Support ownership.

AI-Assisted Customer Communication

The customer proposed an AI-enabled virtual assistant capable of supporting follow-ups and meeting scheduling.

The main risk was allowing automated actions to reach customers without sufficient contextual review.

The selected improvement approach is human-in-the-loop automation.

Future AI-assisted functionality should:

• Generate recommendations rather than final decisions.
• Draft messages or meeting proposals.
• Display the information used to generate the recommendation.
• Require employee approval before customer communication.
• Record the approval and final action.
• Allow employees to edit or reject the recommendation.
• Protect confidential customer and opportunity information.

KPI Baseline Collection

The customer's previous operating environment did not consistently record 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 discovery assessment and configured production workflow.

These values should be validated and formally approved by Mah Quests before use in a competency submission. Future implementations will define KPI baselines before configuration begins, documenting the baseline value, measurement period, source of evidence, improvement target, customer owner, reporting frequency, post-implementation result and customer approval for each KPI.

Ongoing Customer Support

Mah Quests identified the need for further assistance and advanced feature training as its use of the platform expanded.

Tati Software’s continuous improvement process includes:

• Reviewing CRM adoption.
• Monitoring data quality.
• Reviewing qualification rules.
• Reviewing lead scoring outcomes.
• Identifying inactive opportunities.
• Refining dashboards and reports.
• Supporting migration activities.
• Assessing integration requests.
• Introducing relevant platform improvements.
• Providing additional user training.

The lessons from this implementation have been incorporated into improved discovery, data migration, lead qualification, integration governance, KPI measurement, AI oversight, and customer onboarding processes for future SMB customers.