A sales tech stack audit should produce decisions, not a prettier application list. The useful output is a versioned register showing what each tool does, which workflow and data it touches, what it costs to operate, which controls it passes, what evidence supports the score, and whether the next action is to keep, repair, replace, consolidate, or retire it.
Direct answer. Inventory every paid, free, embedded, pilot, and shadow sales tool; map owners, jobs, users, contracts, data, permissions, integrations, and dependencies; stop any item that fails an applicable legal, security, authority, continuity, or exit hard gate; score the remaining tools on job coverage, workflow fit, evidence of use, control quality, and full cost; then approve one owner, action, deadline, and verification test per tool.
The rubric and thresholds below are Gangly editorial methods, not universal benchmarks and not legal, security, accounting, or procurement advice. Tailor the gates to applicable law, contract, risk appetite, sales motion, and system architecture. Record denominators and uncertainty. A tool does not become safe or valuable because a weighted average hides a critical failure.
Set the audit boundary and decision record
Freeze the population before evaluating it. State the business units, teams, regions, environments, data classes, systems, workflow stages, contract entities, and as-of date. Include CRM add-ons, browser extensions, meeting bots, enrichment credits, dialers, sequencing features, AI assistants, marketplace apps, custom scripts, spreadsheets used as systems, free trials, and features bundled inside a larger platform. Mark discovered items added after the freeze rather than silently changing the denominator.
The audit is not the same as a sales workflow audit. A workflow audit diagnoses how work and evidence move through a sales motion. This audit asks whether the technology portfolio supports that motion with acceptable authority, risk, cost, and exit options. Run the workflow audit first when the team cannot state what job a tool should own.
Create an audit charter with sponsor, coordinator, scope, source snapshot, evidence cutoff, reviewers, conflict-of-interest disclosures, scoring version, applicable gates, approval authority, change freeze, decision date, and appeal path. Define the allowed decisions before reviewing products:
- Keep: the tool passes every applicable gate and evidence supports continued operation.
- Repair: the job remains necessary, but configuration, adoption, integration, contract, or control needs bounded remediation.
- Replace: the job remains necessary and the current product cannot meet an applicable requirement within an approved plan.
- Consolidate: another platform can own the job without losing required capability, data, evidence, or control.
- Retire: the job is no longer required or can be removed after dependency and retention checks.
Every decision record needs tool ID, decision, reasons, evidence links, dissent, approver, action owner, due date, acceptance test, rollback path, contract notice date, and verification status. A spreadsheet cell reading “cancel” is not an executable retirement plan.
Build an evidence-backed stack inventory
NIST SP 800-53 control CM-8 calls for an accurate component inventory with enough information for accountability and periodic review; CM-8(4) specifically addresses identifying responsible people. NIST is not a commercial sales-stack standard, but the inventory principle is useful: a tool with no accountable owner or system association is not governable. Review the official NIST control catalog and adapt it to the organization rather than claiming compliance from this checklist.
Use procurement and accounts-payable records to find contracts, identity-provider and single-sign-on logs to find access, CRM connected-app and API-client lists to find integrations, expense reports to find card purchases, browser-management or security inventories where authorized, and interviews to find spreadsheets and free tools. Do not use covert employee surveillance. Notify participants, minimize personal data, and keep the exercise focused on systems and workflow evidence.
| Inventory field | Minimum evidence | Why it matters |
|---|---|---|
| Identity and owner | Product, edition, tenant, environments, business owner, technical owner | Prevents orphaned tools and ambiguous accountability |
| Job and population | Required job, workflow stage, eligible roles, active provisioned users | Separates a necessary capability from a familiar logo |
| Commercial terms | Contract entity, renewal and notice dates, minimums, usage tiers, support | Makes the decision executable before the notice window closes |
| Data and authority | Objects, fields, purpose, source of truth, read/write/send/delete actions | Shows blast radius and conflicting writers |
| Access and integration | SSO, roles, service accounts, OAuth scopes, APIs, webhooks, middleware | Exposes hidden privileges and dependency paths |
| Evidence and exit | Logs, accepted outcomes, incidents, exports, retention, deletion process | Supports a decision and makes retirement testable |
Normalize duplicate vendor names and parent-child subscriptions, but keep separate tenants and editions when permissions, data, contracts, or use differ. Record “unknown” rather than guessing. Assign every unknown an owner and resolution date. The inventory is complete only when totals reconcile to the frozen source populations and unexplained differences are listed.
Apply hard gates before weighted scoring
Hard gates are binary conditions that a weighted score cannot offset. Declare which gates apply to each tool before looking at its score. A presentation add-on with no customer data may have different gates from an AI assistant that reads calls and writes CRM records. Document not applicable with a reason; do not use it as a shortcut around missing evidence.
| Gate | Pass evidence | Failure action |
|---|---|---|
| Purpose and owner | Approved business purpose, accountable owner, required job and users | Freeze expansion; assign owner or prepare retirement |
| Legal, privacy, and contract | Approved processing purpose, terms, data locations, retention and required agreements | Stop prohibited processing and escalate to qualified reviewers |
| Authority and access | Named source of truth, allowed actions, least-privilege roles and controlled credentials | Disable unsafe write/send/delete paths or access |
| Security and incident evidence | Required assessment, logging, notification, response contacts and remediation process | Restrict or suspend according to risk and incident process |
| Continuity and recoverability | Failure behavior, backups where applicable, recovery procedure and manual fallback | Block critical dependency status until corrected |
| Export and exit | Tested export of required records, metadata and evidence; deletion and token-revocation plan | Do not deepen lock-in; remediate before renewal where possible |
CISA’s Software Acquisition Guide asks enterprise buyers about supplier incident communication, exercised business-continuity plans, restoration service levels, backups, centralized logging, and patch processes. It is written for government enterprise acquisition and does not automatically define a private company’s obligations. It does provide a useful primary-source prompt set for the supplier evidence gate.
Gate results are pass, conditional pass with time-bounded remediation, fail, or not applicable with justification. A conditional pass requires a compensating control, owner, approver, expiry, and verification date. When the expiry arrives without evidence, the result becomes fail. Never convert a failed gate into a few lost points.
Score every tool on the same 100-point rubric
Score only tools that pass or conditionally pass the applicable gates. Use a 0–4 evidence scale for each criterion: 0 means absent or contradicted; 1 means ad hoc with weak evidence; 2 means partially implemented or inconsistent; 3 means implemented with repeatable evidence; 4 means implemented, measured, and reviewed. Missing evidence scores zero unless the rubric explicitly permits not applicable.
| Domain | Weight | Questions |
|---|---|---|
| Required job coverage | 25 | Does it complete the defined job and exceptions at accepted quality? |
| Workflow and data fit | 20 | Are handoffs, authority, identity, provenance, and reconciliation reliable? |
| Use and operating evidence | 15 | Do eligible users produce accepted outcomes without unmanaged workarounds? |
| Security, privacy, and reliability | 20 | Are access, logging, supplier, failure, and recovery controls evidenced? |
| Economics and exit | 20 | Is full cost justified, allocated, forecastable, and reversible? |
Weighted score = Σ (criterion score ÷ 4 × criterion weight). Example: scores of 3, 2, 3, 4, and 2 across the five domains above yield 18.75 + 10 + 11.25 + 20 + 10 = 70. That is a synthetic calculation, not a recommendation to keep the product. The gate state, evidence confidence, critical weak domains, switching risk, and alternative design still control the decision.
Set local decision bands before scoring and publish them with the rubric version. A useful decision memo shows raw domain scores, weighted result, evidence confidence, gate state, critical exceptions, TCO range, and reviewer notes. Do not compare tools scored under different definitions, periods, populations, or editions without labeling the mismatch.
Map capability coverage and real overlap
Feature overlap is not operational overlap. Two products may both claim “call intelligence,” while one owns recording and consent, another extracts structured notes, and neither can replace the other without breaking a downstream coaching or CRM process. Map each required job to trigger, input, accountable decision, action, output, consumer, exception, evidence, and service level.
Build a capability-to-tool matrix with one row per narrow job, not broad marketing category. Mark primary owner, approved fallback, duplicate, unused, missing, and prohibited. Then trace evidence for the top workflows end to end: account selection, signal detection, outreach, meeting preparation, call execution, notes, CRM updates, pipeline review, coaching, and reporting. The sales tech stack management guide helps organize these layers; this checklist controls the audit decision.
Challenge each apparent duplicate with a replacement test:
- Can the proposed owner perform the required happy path and named exceptions?
- Can it preserve record identity, field authority, history, consent, suppression, and audit evidence?
- Can affected users complete the workflow in their actual role and environment?
- Can integrations, reports, automations, and downstream consumers be migrated?
- Can the old tool be removed without creating a new manual reconciliation job?
If those questions are not tested, label the relationship “possible overlap,” not “redundant.” Use the sales tool consolidation playbook after the audit identifies a defensible consolidation candidate. Consolidation is an implementation program; the audit is the evidence and decision stage.
Test integrations, authority, and data flow
Draw every production edge: source, target, object, field, direction, trigger, frequency, identity key, transformation, middleware, credential, permission, retry, deduplication, error queue, log, owner, and downstream dependency. Include CSV imports, email forwarding, browser extensions, native sync, custom code, workflow automations, and reporting extracts. An integration page saying “connected” proves authentication, not correctness.
For each shared object, name the authoritative system and permitted writers. Test create, update, merge, delete, ownership change, null, stale event, duplicate, out-of-order event, permission loss, expired token, rate limit, partial batch, and timeout after a write. Reconcile source events to accepted final states. Use the CRM data-quality guide to separate source errors, transformation errors, sync failures, and ownership conflicts.
OWASP’s official API Security Top 10 identifies risks that matter to connected sales tools, including authorization failures, unrestricted resource consumption, improper inventory management, and unsafe consumption of third-party APIs. OWASP is an awareness framework, not proof that a specific integration is vulnerable or secure. Use it to design negative tests and ask vendors how they constrain access, endpoints, consumption, versions, and third-party input.
Record accepted-event rate, missing, extra, duplicate, wrong-record, wrong-value, late, retried, rejected, and unresolved counts. “The sync is 99 percent successful” is incomplete without denominator, period, exclusion rule, severity, and the location of the remaining one percent. A single wrong-recipient email or unauthorized ownership change may cross a hard gate even when the aggregate rate looks high.
Audit access, privacy, and supplier controls
Inventory human users, administrators, service accounts, API clients, secrets, OAuth grants, browser extensions, and external collaborators. For each identity, record sponsor, purpose, role, scopes, data reach, environment, authentication method, creation and last-review dates, rotation or expiry, and revocation procedure. Remove or quarantine stale access under the approved identity process rather than deleting blindly during evidence collection.
NIST AC-6 defines least privilege as allowing only the authorized access needed for assigned tasks. Salesforce’s official OAuth scope documentation shows that scopes define the protected resources a connected app can access. These sources support the principle and platform mechanics; they do not tell an auditor which exact scopes a particular sales product requires. Verify the vendor’s documented requirement, the integration user’s permissions, and the effective combined access.
Map personal and sensitive data by purpose, source, geography, processor or subprocessor, retention, deletion, export, model-training use, support access, and incident-notification term. Confirm actual contracts and applicable law with qualified reviewers. GDPR Article 20 includes a right, under specified conditions, to receive certain personal data in a structured, commonly used, machine-readable format. That right is not a blanket rule that every business record must be exportable, but it demonstrates why portability requirements need precise legal and data-scope analysis.
Request evidence appropriate to risk: independent assessment scope and period, unresolved findings, encryption and key responsibility, tenancy, data location, subprocessor change process, incident contacts, logging, vulnerability and patch process, recovery commitments, deletion verification, and secure development practices. Certifications can be inputs, but scope, exclusions, date, and shared responsibility matter. Do not turn a logo on a trust page into a pass.
Test reliability, support, and change control
Review incidents and support records for a defined period. Classify availability, latency, data loss, wrong action, duplicate action, access, billing, vendor change, user error, configuration error, and dependency failure. Report severity, duration, affected workflows, detection source, recovery, recurrence, unresolved action, and evidence gaps. Support ticket count alone can rise because adoption increased or fall because users stopped reporting.
Run a tabletop for vendor outage, CRM outage, identity-provider outage, expired integration credential, schema change, rate limit, corrupted export, pricing or packaging change, and vendor termination. Name the manual fallback, maximum tolerable interruption, queued-work treatment, decision authority, communication path, recovery order, and reconciliation method. Validate critical recovery steps in a safe environment where practical.
Audit configuration and automation changes through the sales automation change-control checklist. Capture versions, tests, approvals, canary cohort, monitoring, rollback, and retirement. For AI features, also record provider and model where exposed, prompt or policy version, data use, review requirement, prohibited actions, evaluation set, and fallback. A product can pass procurement and later drift through configuration.
Assess operability, not only vendor uptime: can administrators explain failures; can the team retrieve usable logs; do alerts reach an owner; can a user correct a bad outcome; are credits and rate limits visible; are breaking changes announced; and can support reproduce the issue? The portfolio inherits the weakest critical dependency in a workflow, so score the complete path as well as individual products.
Calculate total cost beyond license price
Annualized TCO = recurring licenses and usage + implementation and migration + integration and middleware + administration + security, privacy, legal, and procurement review + data and enrichment + enablement and support + exception and reconciliation labor + incident and downtime cost + overlap and exit reserve. Keep taxes, currency conversion, contract commitments, capital treatment, and internal labor rules consistent with finance policy.
Build the calculation from invoices, contract schedules, usage exports, cloud or middleware bills, administrator time records, support evidence, and migration plans. Where exact values are unavailable, show a low/base/high range and the assumption owner. Use the sales admin time audit template before assigning a labor value to rep work. Self-reported minutes and telemetry each have blind spots, and neither proves that a product caused a downstream sales result.
Allocate shared cost through a documented driver such as active eligible users, accepted outputs, teams, territories, or workflows. The FinOps Foundation’s allocation capability describes assigning direct and shared costs to accountable groupings using metadata and explicit shared-cost mechanisms. It is a cloud-finance framework, so this article adapts the allocation idea to sales technology rather than presenting it as a required accounting method.
Worked fictional TCO example. A 60-user tool has $72,000 in annual licenses and usage. Finance annualizes a $36,000 implementation over its approved three-year analysis horizon, adding $12,000 per year. The base case also includes $9,600 for middleware, $18,000 for administration, $6,000 for security and procurement review, $14,400 for data, $8,000 for enablement and support, $7,200 for exception and reconciliation labor, a $4,000 incident-cost estimate, and a $10,000 exit reserve. Annualized TCO is $72,000 + $12,000 + $9,600 + $18,000 + $6,000 + $14,400 + $8,000 + $7,200 + $4,000 + $10,000 = $161,200.
At the declared 60-user allocation, the base-case cost per eligible user is $161,200 ÷ 60 = $2,686.67 per year. That unit cost does not establish value or justify renewal. The model must also show low and high cases for uncertain labor, incident, usage, migration, and exit inputs; identify the owner of each assumption; and compare candidates at the same scope and period. If finance uses a different treatment for implementation or reserves, preserve that treatment rather than copying this illustration.
| Cost lens | Formula | Caveat |
|---|---|---|
| Cost per eligible user | Allocated annualized TCO ÷ eligible users | Direct logins may not reflect infrastructure value |
| Cost per accepted outcome | Allocated period TCO ÷ accepted outputs | Define quality and deduplication before counting |
| Unused commitment | Committed quantity − consumed eligible quantity | Contract minimums and seasonal use can distort one month |
| Switching range | Migration + overlap + validation + training + exit costs | Include rollback and delayed retirement, not only data import |
Do not subtract a generic productivity claim from TCO. Credit a benefit only when the local audit defines the baseline, accepted outcome, observation period, source, confidence, and alternative explanation. A tool can be worth keeping without a causal revenue claim if it satisfies a mandatory job or control at an approved cost.
Prove export, migration, and clean exit
An untested export option is not an exit plan. Inventory required records, objects, attachments, recordings, transcripts, templates, prompts, sequences, consent and suppression state, user and ownership mappings, audit logs, configuration, custom fields, relationships, timestamps, and stable identifiers. Separate data the organization owns, data licensed only for use, derived scores, and vendor-only metadata.
Run a representative export before renewal. Record request method, permissions, time, format, field coverage, relationships, encoding, timezone, attachments, pagination, rate limit, schema, checksums or row reconciliation, and errors. Import a sample into a neutral staging area or candidate system and verify semantic meaning, not only file readability. Test incremental changes during the migration window and preserve the old-to-new ID map.
Read the contract for notice, assistance, access after termination, export charges, deletion timing, backup retention, legal hold, subprocessor deletion, domain or number portability, and continued evidence access. Ask how queued actions, webhooks, marketplace packages, browser extensions, service accounts, API tokens, DNS records, phone numbers, sending domains, and downstream automations are disabled.
Retirement completes only after final reconciliation, required retention or archive, replacement acceptance, dependency removal, credential revocation, access removal, scheduled-job shutdown, contract closure, deletion request and evidence where applicable, documentation update, budget update, and post-cutover monitoring. Preserve an approved rollback window when possible. Pausing a license while active integrations keep writing is not retirement.
Choose keep, repair, replace, consolidate, or retire
Bring gate state, domain scores, evidence confidence, TCO range, contract timing, migration risk, dependencies, user impact, and alternative designs into one decision table. Compare the current product with the manual baseline, a repaired configuration, a consolidated owner, and a replacement only when those options meet the same job definition and gates.
| Decision | Use when | Required proof |
|---|---|---|
| Keep | Gates pass and evidence supports the required job at accepted cost | Owner, controls, review date, renewal record |
| Repair | Fixable configuration, integration, adoption, contract, or control gap exists | Bounded plan, owner, expiry, verification test |
| Replace | The job remains required and a critical need cannot be met acceptably | Matched pilot, migration, rollback, TCO, approvals |
| Consolidate | Another tool passes the full replacement test for this job | Capability and exception parity, dependency and exit tests |
| Retire | The job can be removed or is safely owned elsewhere | Archive, reconciliation, revocation, deletion, contract close |
Avoid portfolio-level targets such as “cut five tools” before the evidence is collected. They reward easy counts and can remove a low-cost control while preserving an expensive duplicate. Decide by required job and risk, then use the consolidation playbook to execute grouped migrations in dependency order.
Gangly can be evaluated as one workflow option where teams want connected signal detection, outreach assistance, call preparation, live coaching, post-call notes, and CRM suggestions. It should face the same job, authority, evidence, TCO, security, integration, and exit tests as every other candidate. Product breadth does not waive the gates.
Run the audit and govern the next cycle
A practical audit can run in four controlled phases. First, freeze scope and reconcile the inventory. Second, collect contracts, access, data-flow, usage, incident, cost, and export evidence. Third, apply gates and independent scoring, then adjudicate disagreements. Fourth, approve actions and verify them. Do not compress the process into a vendor survey; observed configuration and source-system evidence matter.
- Kickoff: approve charter, population, roles, evidence requests, rubric, gates, and deadlines.
- Discovery: reconcile finance, identity, CRM, integration, security, and team sources.
- Testing: sample workflows, permissions, integrations, failures, usage, costs, and exports.
- Decision: have at least two relevant reviewers score independently before adjudication.
- Execution: route repair, replacement, consolidation, and retirement through change control.
- Verification: confirm acceptance tests, savings realization, access removal, and final records.
Maintain a lightweight quarterly reconciliation of new tools, owners, renewals, access, critical integrations, incidents, and exceptions. Trigger an out-of-cycle review for a security event, material contract or packaging change, new regulated data, acquisition, CRM migration, owner departure, repeated failed reconciliation, or major workflow redesign. Keep old versions so a past purchasing or access decision can be explained.
Report portfolio counts with denominators: inventoried, gate pass, conditional, fail, unscored, keep, repair, replace, consolidate, retire, complete, overdue, and unknown. Also report expected and realized cost changes separately. A planned saving is not realized until invoices, usage commitments, internal work, and replacement costs reconcile after the change.
Copy the sales tech stack audit checklist
| Control | Evidence artifact | Status |
|---|---|---|
| Scope, population, as-of date, rubric, gates, and approvers are frozen | Audit charter and version | □ |
| Finance, identity, CRM, integration, expense, and team sources reconcile | Inventory reconciliation log | □ |
| Every tool has one owner, required job, eligible users, and contract record | Stack register | □ |
| Objects, fields, actions, authority, integrations, and dependencies are mapped | Data-flow and authority map | □ |
| Applicable purpose, legal, access, security, continuity, and exit gates pass | Gate evidence pack and exceptions | □ |
| Scores use the same 0–4 definitions, period, and documented evidence | Independent score sheets | □ |
| Critical workflows and exceptions pass end-to-end integration tests | Test and reconciliation report | □ |
| Access, scopes, service accounts, logs, incidents, and supplier evidence are reviewed | Security and privacy review | □ |
| TCO includes internal operation, risk, overlap, and exit with assumptions | Low/base/high cost model | □ |
| Representative export preserves required records, relationships, and evidence | Export and sample-import test | □ |
| Keep, repair, replace, consolidate, or retire has owner and acceptance test | Approved decision register | □ |
| Actions are verified and next review triggers are scheduled | Closure report and review calendar | □ |
The strongest stack is not necessarily the smallest or the one with the highest average score. It is the smallest defensible set of systems that owns every required job, preserves authority and evidence, passes applicable gates, operates at an approved total cost, and can be changed or exited without losing control of customer data and revenue work.