Sales tech stack: how to integrate your commercial tools
The company buys one tool per problem and ends up with ten systems that do not talk to each other, retyped data and three versions of the same number. A sales stack works when each layer has a function, an owner and a defined piece of data it returns to the CRM.
The sales tech stack is the set of systems that marketing, sales and customer success use to attract, sell, invoice and serve the customer, and it only brings predictability when the CRM works as the source of truth and every tool around it has a function, an owner and a defined piece of data it returns to the customer record. Most of the companies I work with reached their current stack by accumulation. Each team bought a tool to solve the problem of the quarter, and a few years later the operation runs ten systems that do not talk to each other, with salespeople copying information from one screen to another and an executive team that cannot say which number counts. Before the next purchase, leadership needs to decide which system owns each piece of data, who answers for each integration and which criterion decides whether a license renews or goes.
The typical scene happens when the CFO asks how many active customers the company has. The CRM shows one number, the ERP shows another based on who paid the last invoice, and the customer success spreadsheet brings a third, which includes accounts still in onboarding. All three are right, because each system answers a different question and the company never wrote down which one answers for the official number. The waste also shows up in the license bill: in a survey of 405 marketing leaders, Gartner found that companies used on average 33% of the capability of their marketing technology stack, and another Gartner survey, cited in the same release, showed that this technology consumed 25.4% of the marketing budget (Gartner, 2023). Respondents named the complexity of the ecosystem, customer data challenges and inflexible governance as the main obstacles to using more of what they already paid for.
Why does the sales stack grow without a design?
Buying by problem follows a familiar script. Marketing needs landing pages and signs up for a tool, sales wants to call faster and subscribes to a dialer, customer success gets complaints over WhatsApp and puts a support number live, and the sales team adopts an e-signature tool. Each decision makes sense on its own, fits on the team’s corporate card and goes through without IT seeing it. The demo showed a native integration with the CRM, and nobody asked which fields sync, in which direction, or what happens when the record already exists on the other side.
A year later, the salesperson works with six tabs open, the customer history is scattered and the monthly report requires someone exporting four spreadsheets and matching everything by company name. The root of the problem sits before the technology, and I cover it in Revenue Operations in practice: without a written process between teams, each one buys the tool that solves its own part, and the stack reproduces the silo that already existed in the org chart.
What are the layers of a RevOps stack?
I design the stack in layers around the CRM, and the question that defines each layer is which data it needs to return to the customer record. A tool that does work and returns nothing creates a parallel history that only its user can see, and that history disappears when the user changes jobs. The table below is the starting point I use with leadership teams.
| Layer | Function in the operation | What it must return to the CRM | Typical owner |
|---|---|---|---|
| CRM | Single record of companies, contacts, deals and activities; pipeline and forecast | It is the destination: it receives, consolidates and shows data on the customer record | Revenue operations, with the leaders |
| Marketing automation | Forms, email, nurturing, landing pages and lead scoring | Lead source and campaign, conversions, score and communication consent | Marketing |
| Prospecting and enrichment | Lists, company and contact data, outreach cadences | Company size, segment, tax ID, job title, data source and date, contact attempts | Sales development |
| Conversation, telephony and WhatsApp | Calls, messages, meeting recording and transcription | Activity with date, duration, outcome and summary, linked to the deal | Sales and support |
| Proposals and e-signature | Building the proposal, versions, discount approval and signature | Value, products, discount, version sent, signature date and contract | Sales, with legal |
| Customer support | Tickets, knowledge base and satisfaction surveys | Ticket volume and type per account, satisfaction and resolution time | Customer success |
| ERP and finance | Invoicing, tax invoices, collections and delinquency | Invoicing status, overdue items and realized revenue per customer | Finance |
| BI | Consolidation and analysis across systems | Nothing; it reads the master systems and publishes dashboards | Revenue operations or data |
| AI | Summaries, classification, next step suggestions and agents | Records reviewed by a person, with the source flagged | Revenue operations, with IT |
The CRM as the source of truth, and of what
The CRM owns the commercial relationship: who the customer is, who the contacts are, what stage each deal is in, what was agreed and who owns the account. It does not need to own invoicing, which belongs to the ERP, or the technical ticket, which belongs to the support tool. It needs to show that data on the customer record, so the salesperson knows about the overdue invoice before calling to offer an expansion. Choosing the platform comes after this definition, and the research criteria are in the best B2B CRMs in 2026.
The layers that leak the most information
In the operations I assess, conversation and proposals are the layers that leave the most data outside the CRM. WhatsApp on the salesperson’s phone holds the whole negotiation, and when that person leaves the company the conversation goes too. A proposal edited in a loose file reaches the customer with a discount the CRM never recorded, and the closed-won value starts to differ from the signed contract. Both layers need an integration that writes the activity to the deal and a written rule for whatever stays outside it.
BI and AI: the layers that read the operation
BI and AI depend on the other seven layers. BI combines what the master systems recorded, and if the same customer appears with three spellings, the dashboard counts three customers. AI summarizes meetings and suggests next steps with the quality of the history it finds. I recommend that neither of them write to a critical CRM field without a person’s review and without flagging the source, so the team can tell what came from the salesperson and what came from the model.
Which system owns each piece of data?
The data map between systems is the document that states, field by field, which system is the master, which systems read or receive a copy and in which direction the information travels. It ends the argument about the three active customer counts, because the definition now has an address. The map’s rule gives each piece of data a single master system. If two systems edit the same field, two-way sync overwrites someone’s correction, and the team loses track of which version was right.
| Data | Master system | Who reads or receives a copy | Direction | Frequency |
|---|---|---|---|---|
| Legal name, tax ID and billing address | ERP | CRM and proposals | ERP to CRM | At registration and daily |
| Contact, job title and account owner | CRM | Automation, support and conversation | CRM to the others | Continuous |
| Communication consent and preferences | Marketing automation | CRM and conversation | Automation to CRM | Continuous |
| Lead source and campaign | Marketing automation | CRM and BI | Automation to CRM | Continuous |
| Stage, forecast value and deal owner | CRM | Proposals and BI | CRM to the others | Continuous |
| Contracted value, products and discount | Proposals and e-signature | CRM and ERP | Proposals to CRM and ERP | At signature |
| Invoicing, payment and delinquency | ERP | CRM and BI | ERP to CRM | Daily |
| Tickets and satisfaction | Customer support | CRM and BI | Support to CRM | Daily |
The consent row calls for legal’s attention: if the WhatsApp tool does not read that the contact asked to opt out, the salesperson fires the cadence at someone who had already declined. The map also shows where quality gets lost. The registration, duplicate and required field rules that keep the master system reliable are in CRM data quality. The most sensitive stretch is usually the handoff from signed contract to invoicing, which crosses proposals, CRM and ERP on the same day, and I detail that path in lead to cash, the full route from lead to money in the bank.
Who owns each integration?
An integration without an owner breaks without warning. Someone renames a pipeline stage, the rule that sent the closed-won deal to the ERP stops firing, and finance finds out weeks later, when the customer complains about not receiving the invoice. I ask for a short sheet for each integration, kept next to the data map. It records what syncs, in which direction, which event triggers the sync, what happens when it fails, who receives the alert and who approves changes to the fields involved.
Responsibility splits by the nature of the work. IT answers for access, security, the vendor contract and compliance with the company’s data policy. Revenue operations answers for the logic: which fields travel, which rule fires and which system owns the data, according to the map. The business team answers for usage and tells operations when the process changes, before changing the field. In a smaller company, one person can hold the roles, as long as the name is on the sheet.
Between the vendor’s native connector, an integration platform (iPaaS, a tool that connects systems through configured rules, without coding) and custom code, I choose the simplest option that covers the rows of the map. Custom code requires documentation and more than one person who understands it, or the integration stops on the day the developer leaves the project.
How do you build an inventory of commercial technology licenses?
The inventory starts in accounts payable, because a tool bought on the team’s card almost never went through IT. Finance lists software vendor payments from the last twelve months, reimbursements included, and IT matches the list against corporate single sign-on. For each tool, record category, owner, contracted licenses, active users in the last 30 days, monthly cost, renewal date, cancellation notice period, integrations and where the data goes if the contract ends. The notice period deserves its own calendar, because in many annual contracts it expires weeks before the renewal.
The number that changes the conversation is cost per active user. In a hypothetical example, a conversation tool costs R$ 6,000 a month for 40 licenses, or R$ 150 per license on the contract. If 16 people used it in the last 30 days, cost per active user reaches R$ 375, two and a half times the figure the team presented when it asked for the purchase. An executive team that looks only at price per license approves renewals that, measured by usage, it would reject.
How do you decide what stays and what goes in the sales stack?
The evaluation table below serves both decisions: renewing or cutting what is already in the stack, and approving or rejecting what someone wants to buy. Each criterion has an objective cut signal, so the meeting does not turn into a defense of personal preference.
| Criterion | Question | How to measure | Cut signal |
|---|---|---|---|
| Real usage | Who used it in the last 30 days, and for what? | Active users divided by contracted licenses, from the tool’s access log | Fewer than half of licenses active for two months in a row |
| Integration | Does the data return to the CRM without retyping? | Rows of the data map that the integration fills | The team copies data by hand or exports a spreadsheet every week |
| Owner | Does someone answer for the tool and its integration? | Name on the integration sheet and in the inventory | Nobody knows who administers the account |
| Cost per active user | How much does each person who uses it cost? | Monthly cost divided by active users | Higher than what the team accepts to pay for the result it delivers |
| Overlap | Does another tool in the stack already cover this function? | Repeated functions in the same inventory layer | Two tools in the same layer, one per team |
| Data exit | Can the company take the history if it ends the contract? | Full export test with attachments and activities | History locked with the vendor or on the salesperson’s phone |
I treat a tool that fails two criteria as a candidate for cutting at the next renewal. One that fails integration and ownership at the same time counts as a risk even with high usage, because it holds a history the rest of the company cannot see.
Before buying the next tool
Whoever requests the purchase describes the process problem the tool solves, the layer it occupies, the data it returns to the CRM and through which integration, who will own it and what leaves the stack if it comes in, with the training plan for the people who will use it. In the contract, legal checks the data export clause and the cancellation notice period.
How to cut without losing history
The cut starts with exporting activities, attachments, recordings and custom fields to the CRM or to a company repository, with the data map updated. A short overlap period follows, in which the owner checks that nothing stopped reaching the CRM, and finance only cancels the contract after the owner confirms the full export.
What changes for each leader?
Sales and marketing
For the sales leader, an organized stack removes tabs from the salesperson’s screen and, in return, the manager starts requiring WhatsApp and meeting activity to appear on the deal, because the monthly forecast depends on that history. The marketing leader stops defending campaigns with the automation tool’s report and starts reading revenue by source in the CRM, which requires the lead source to travel intact all the way to the closed-won deal.
Customer success
Customer success opens the ticket on the same record that holds what was promised, who negotiated and what discount the customer received. The CS leader, in turn, returns ticket volume and satisfaction per account to the operation, which feed the churn risk alert.
IT and finance
IT stops discovering tools after the purchase and starts approving their entry through the data map and the security policy. Finance takes over the inventory, the renewal calendar and cost per active user. With the ERP as the invoicing master, finance compares contracted revenue with invoiced revenue without asking for spreadsheets and catches early the contract that never became an invoice.
A roadmap for leadership to organize the sales stack
The roadmap fits in one quarter in a mid-sized operation, and the first three steps require no purchase.
- Build the inventory. Finance, IT and leaders list each tool with usage, owner, cost and integrations.
- Draw the layers. Place each tool in a layer and flag the overlaps.
- Write the data map. For each piece of data the executive team uses in decisions, define master, readers, direction and frequency, with the leaders signing off.
- Name the owners. Each integration gets its own sheet.
- Fix the integrations that carry money first. Start with the signed contract that goes to invoicing and the lead that reaches the CRM with its source, before any new dashboard.
- Prepare the people who operate. Each profile learns what to record, where and who uses that data afterward.
- Put the renewal rule in place. Every renewal goes through the leadership meeting, and every purchase request through the evaluation table.
Sales stack and L&D: what HR needs to assess
How to recognize the need
The signs show up in usage before they show up in the budget: the tool rolled out three months ago has half its licenses idle, and analysts build spreadsheets to combine data that should live in one place. A new tool without training becomes one more idle license, and the Gartner analyst, in the 2023 release, attributed part of the low utilization to buying technology without an adoption method. The reasons teams work around the system are in CRM adoption.
Who takes part
Training starts with the leaders who decide the stack: sales and marketing executives, customer success, IT and finance, together with whoever will maintain the map and the sheets. This group writes the map and applies the evaluation table to the company’s own stack. Then comes role-based training for the people who operate, from SDRs to support agents, with the direct manager present to hold the team to the agreement in the following weeks.
How to measure
Before the training, record the share of active licenses per tool, the number of map rows filled by integration, the time the team takes to close the monthly report and how many parallel spreadsheets circulate in the leadership meeting. Ninety days later, compare the same points.
If your company pays for tools that do not talk to each other and the executive team argues about which number counts instead of deciding, that is the work of the in-company Revenue Operations training. I run the program with the marketing, sales and customer success leaders, IT, finance and the operations person in the same room, on your operation’s stack and data. The group leaves with the SLA between marketing, sales and CS, which defines what each team delivers to the next, and with the RevOps metrics matrix, which points to the system each number comes from and serves as the basis for the data map.
Frequently asked questions
What is a sales tech stack?
A sales tech stack is the set of tools a company uses to attract, sell, invoice and serve the customer, from the CRM to marketing automation, from telephony to the ERP. It works when the CRM holds the commercial relationship and each tool has an owner and returns to the CRM a piece of data defined in the data map.
Which tools does a B2B sales stack need?
The CRM is the only mandatory item from the start. The other layers, such as marketing automation, prospecting, conversation, proposals, support, ERP, BI and AI, come in as the process requires and as the company can name an owner and an integration for each one. A small operation works well with a few integrated layers.
Does the CRM need to be the source of truth for all data?
The CRM needs to be the source of truth for the commercial relationship: contacts, deals, stages, activities and account owner. Invoicing and delinquency belong to the ERP, and tickets belong to the support tool. The CRM shows that data on the customer record, and the data map defines which system owns each item.
Who should own the integrations, IT or RevOps?
Both, with different roles. IT answers for access, security and the vendor contract, and revenue operations answers for the integration logic, with the fields, the rules and the master system for each piece of data. The name of each person in charge is written on the integration sheet.
How do you know whether a tool should be cut?
Assess real usage, integration, ownership, cost per active user, overlap with other tools and the ability to export the data. A tool that fails two of these criteria is a candidate for cutting at the next renewal. Before cancelling, export the history and check the notice period in the contract.
How do you train the team to use the sales stack?
Start with the leaders who decide the stack, so they write the data map and the renewal rule on the company’s own tools. Then train each operating role on what to record, in which system and why, with the direct manager in the room. Measure through license usage and the parallel spreadsheets that stop circulating.
Want to bring this to your team?
In the in-company Revenue Operations training, leadership designs the SLA between marketing, sales and CS and leaves with the operation's metrics matrix.
More writing on the same subject.

RevOps team: roles, structure and when to hire
Many companies hire a CRM analyst and expect that person to fix process, data, tools and reporting alone. This guide covers the four roles of a RevOps team, how it grows with the company, who it should report to and how HR builds the job description and the training path.
17 min readRead more
Sales planning: how to calculate quota and team capacity
A target born from "grow 30%" without checking the funnel and the team turns into pressure by the second quarter. The bottom-up math starts with the customer base, runs through deal size, conversion, cycle, rep capacity and ramp, and shows how many people to hire, when, and how much pipeline the year needs.
18 min readRead more
Lead to cash: from first contact to invoicing
A sale ends when the first payment reaches the bank, and between "won" in the CRM and that day come the quote, approval, contract, ERP registration, invoice, collection and delivery. The lead to cash process gives each handoff an owner, defines the fields that travel from the CRM to finance and measures the time to cash.
17 min readRead more