To offer or not to offer professional services, that is the question. In the B2B SaaS universe, this is a dilemma that is frequently presented to founders, especially those who are already with the product generating revenue and building a business process to expand their client base and continue to grow.
The story is well known. After acquiring the first customers, requests for specific features, workflow adjustments, and customized integrations appear. In order to keep these clients happy, part of the team start working on personalized onboardings and setups, product modifications, and specialized service.
Within a few months, within the startup, an operation of professional services is born with the objective of directly educating and supporting customers, maximizing product adoption. In the medium and long term, however, this situation tends to pose a dilemma: this part of the team dedicates more time to customer requests than to developing the technological core of the software, threatening the company's scalability.
Faced with this impasse, founders must adopt a professional services strategy aligned with business growth interests. In this article, we bring some of the main reflections to be contemplated during this process.
Paracelsus's maxim
Paracelsus was a 16th century Swiss doctor, who became known as the “Father of Toxicology”, precisely because he defended the use of toxic chemical agents, such as mercury and arsenic, to treat diseases, provided that the correct measures were taken. “The dose makes the poison” is one of his most famous conclusions.
This maxim changed over time. “The difference between medicine and poison is in the dose” became a popular saying in Brazil, serving as advice in countless situations, including in the business world. For the dilemma of professional services in SaaS, it will also suit us.
A survey conducted in 2024 by Sammy Abdullah, from Blossom Street Ventures, shows that the presence of professional services in SaaS companies is considerable. Of the 77 companies with this business model that have held an IPO since 2017, 37.6% had revenue from non-recurring activities, such as setup, integrations, onboarding, and customizations.
As Paracelsus's maxim recommends, the dose is essential to determine if something is medicine or poison. Of the companies that offered professional services and reached the IPO, the median and average participation of these functions in the ARR was 10% and 14%, respectively. These values indicate a balance between the weight of personalization and scalability: somewhere between 10% and 15% of SaaS company revenues.
Thought Framework: structuring professional services in SaaS
Each SaaS company presents a different reality of people, processes, and product. It is these peculiarities that will dictate the way in which professional services should be structured in organizations. For founders facing this dilemma, we propose a thought framework organized in categories that naturally follow one another.
1. Understand your Product
Before any discussion about professional services, It is necessary to be absolutely clear about the product itself, both of its present, what it is and how it delivers value, and of its future, what it may become.
Define what is the technological core
The first exercise is to define precisely what constitutes the technological core of the product, as well as what features and functionalities can be adjusted or customized. This understanding needs to be grounded and pacified internally before any conversation with customers about customizations.
Fábio Piastrelli, founder of Gera, learned in practice that “the 'no' list is as important as the roadmap”. Basic visual changes, such as colors, field names, and logos, may be acceptable to customize for some businesses. However, changes in the screen structure and core features create a large technical effort, burdening technology teams and making it difficult to standardize training materials.
Without the clarity of what is fundamental, each customization request becomes a philosophical discussion. With an established definition, decisions become faster and more consistent. The list of what can be customized must be shared with the entire sales and CS team to avoid promises that are incompatible with the product strategy.
What becomes code?
One of the most traditional ways of building a product is the transformation of processes carried out in a manual, non-scalable way into code.
That's what our General Partner Edson Rigonatti Call of “templatization”: all human work must be documented in replicable processes, workflows, and patterns to then become a technology with a high degree of distribution.
The point is that templatization not only serves the technological core of the product, but also to develop the roadmap. After all, if an adjacent manual task can be documented in replicable processes, it can also be encoded in other product resources.
In this sense, everything that is not possible to transform into code must be attended by humans and, therefore, be part of professional services.
Clarity in the product roadmap
Another relevant exercise is to have a well-defined and documented product roadmap. Being able to establish these priorities among everyone on the team is essential for a simple reason: customizations requested by clients may already be foreseen in the pipeline.
When a customer asks for a feature that is already covered by the roadmap, the conversation changes, as you gain a negotiation lever.
In addition, a structured development plan allows you to identify patterns. If three customers requested variations of the same problem, it is possible to categorize them as a priority demand in the development backlog.
Create a decision algorithm to evaluate customizations
Before accepting any demand from customers, it is worth applying an evaluation filter. Our General Partner Edson Rigonatti proposes an algorithm with five essential questions that help founders make these decisions:
- Is this customization necessary to win the customer?
Assess whether it's really a deal-breaker or just an interesting idea to develop. - How much does it cost to deliver?
Understand how many resources the organization will commit to meeting customer demand. - If we develop, will other customers also pay for it?
Better commit resources to meet a customization that solves the problem of multiple customers. - Who is funding this development?
Does the customer finance 100%? Or does the company subsidize part hoping to generalize the functionality? - What is the expected margin?
Customization needs to be financially sustainable, considering not only development, but potential ongoing maintenance.
2. Establish Governance
With a deep understanding of the product and established decision criteria, the question naturally arises as to how decisions will be made and who has the authority to make them within the organization.
When a large customer demands customization that the product team considers harmful to the roadmap, who has the final word? When CS promises a feature that the technology team didn't prioritize, how is that issue resolved?
Without very well defined scopes, the chance of generating friction between different areas and making inconsistent decisions increases. These rules must be discussed, documented, and shared with all teams, especially sales, CS, and product teams.
3. Structure Architecture and Integrations
Some technical decisions, such as product architecture and the number of integrations developed for other systems, can be a differential in dealing with customer and lead requests.
Isolating core customizations
The fundamental question is whether the product's current technology architecture allows it to isolate customizations from the base software. Migrating to microservices architecture, in theory, allows customizations to be isolated, that is, clients or partners can develop their own functionalities without impacting the core.
In practice, however, migrating to microservices has a significant cost and considerable complexity, precisely because of the resources committed to infrastructure, DevOps, and specialized teams. However, this may be a necessary investment when the number of customizations begins to compromise the agility of product development.
Decide which integrations to pre-build
For new or evolving products, there's a decision about how many native integrations to develop. Pre-integrating with the main tools in the market (ERPs, CRMs, automation platforms) accelerates implementation and reduces dependence on customized services.
Fábio Piastrelli, from Gera, considers pre-integration mandatory for modern products. However, this implies a responsibility on the technology team: to monitor the version updates of the integrated systems, a continuous maintenance operation that cannot be underestimated.
To make good use of the available ecosystem of solutions, a study is necessary on what integrations are necessary to cover 80% of the systems used by the market. This research is essential, since making all the technical connections is not feasible, while making few burdens the professional services team.
4. Design Operational Processes
The next challenge for a SaaS lies in the tactical and operational aspects, ranging from the pricing of professional services to the development of a good process for implementing data with clients.
Establish a pricing model
The pricing of professional services is one of the most relevant decisions and one of the most varied in the SaaS market. There is no single model, as companies adopt different approaches depending on their positioning, customer profile and competitive strategy.
Some companies charge for all professional services: onboarding, premium CS, and assisted operation. Other organizations adopt hybrid models with basic training included in the first year of the contract, but with charges for customized integrations and premium support.
At Gera, for example, Piastrelli implemented a creative approach: the customer pays 50% of the development if they allow customization to be incorporated into the product or can pay 100% of the amount to maintain exclusivity.
Structure processes for data quality
This is often one of the main bottlenecks of SaaS implementations. Data from internal customer systems presents recurring problems: format inconsistencies, duplicates, and incomplete records. This comes with a built-in risk, as an inadequate setup can add months to the schedule and generate extra costs.
A practice that has gained relevance in the market is the execution of robust data planning before starting the implementation. Thus, a plan is drawn up about which data sources will be used, the current status of that information, and how it will be processed, stored, and made available.
For products that rely heavily on data quality, it's worth investing in validation, cleaning, and preparation processes before onboarding.
5. Build the Team Structure
The structure of professional services teams varies according to the business model and the company's stage, but some patterns can be seen in the market, with a distribution of professionals in three major categories:
- Onboarding/Implementation It is the team dedicated to implementing the tool as soon as possible in the client's operation.
- Customer Success begins after deployment, focusing on adoption, expansion of use within the installed base, identification of upsell and cross-sell opportunities.
- Training/Education it can integrate onboarding or operate separately, but always acting with the objective of creating reusable materials, such as certifications, documentation and tutorials to increase the client's proficiency in the use of its tool.
The decision about how many of these roles to create and when depends on the company's stage. Early-stage startups often accumulate roles, with the same person doing onboarding, training, and CS. As they scale and the volume of clients grows, specialization becomes necessary to maintain quality and efficiency.
.avif)
