What SaaSpend is for

Getting started with an inventory paste

Preparing the SaaS list

I start by exporting a list of all active subscriptions from our finance system. The export includes the vendor name, the product SKU, the monthly cost, the owner email, and the renewal date. I save the file as a plain‑text CSV and open it in a spreadsheet to verify that each row has a value in the vendor column. Missing vendor names cause the parser to skip the row, so I fill in any blanks before copying.

Pasting into the tool

I copy the entire CSV content, including the header row, and paste it into the large text box on the SaaSpend homepage. The tool expects a tab‑separated or comma‑separated format; it automatically detects the delimiter. After pasting, I click the “Analyze” button. The parser reads each line, normalizes vendor names (for example, turning “Slack Technologies, Inc.” into “Slack”), and builds an internal catalog of services.

What the parser expects

The parser looks for three key fields: vendor name, subscription cost, and owner email. If any of those fields are missing, the line is flagged and shown in a warning panel at the top of the results. I can correct the source CSV and re‑paste, or I can edit the entries directly in the inline table that appears after the first pass. The tool also ignores lines that contain only comments or blank lines, which helps when I paste a report that includes explanatory notes.

Finding category overlaps across tools

How categories are mapped

SaaSpend maintains an internal taxonomy of SaaS categories such as communication, project management, file storage, and identity management. When a vendor is recognized, the tool assigns it to one or more categories based on a curated mapping table. For example, “Microsoft Teams” maps to both communication and collaboration, while “Dropbox Business” maps to file storage and backup. I can view the mapping for any entry by hovering over the vendor name in the results grid.

Detecting duplicates

After categorization, the tool scans each category for multiple vendors that provide overlapping functionality. It uses a similarity score based on feature tags (like “video conferencing”, “task board”, “e‑signature”) and on the description text supplied by the vendor. If two services share a high similarity score and are owned by different teams, they appear as a duplicate pair. The tool also surfaces cases where the same vendor appears under different SKUs (for instance, “Zoom Pro” and “Zoom Enterprise”) and treats those as potential overlaps.

Visualizing overlap

The results page shows a collapsible list per category. Expanding a category reveals a table with columns: Vendor, Monthly Cost, Owner, Similarity Score, and Suggested Action. I can sort by cost to see the most expensive overlaps first, or by similarity score to focus on the closest matches. A small bar chart next to each pair visualizes the overlap percentage, making it easy to spot groups where three or more tools serve the same need.

Generating cut/keep recommendations

Scoring usage signals

I upload a usage report from our SSO provider that lists the number of logins per user per month for each application. SaaSpend merges this usage data with the cost data to calculate a cost‑per‑active‑user metric. Applications with low usage and high cost receive a low efficiency score. The tool also looks at renewal proximity; contracts that renew within the next 30 days are flagged for early review.

Cost vs value matrix

To help decide which tool to keep, I open the built‑in matrix view. The X‑axis shows the monthly cost, the Y‑axis shows the average monthly active users. Each bubble represents a service; the size of the bubble indicates the similarity score with other services in the same category. Bubbles in the upper‑left quadrant (high users, low cost) are strong candidates to keep. Bubbles in the lower‑right quadrant (low users, high cost) are candidates to cut. I can drag a bubble to adjust the cost or user count if I have updated numbers from a recent invoice.

Producing the action list

After reviewing the matrix, I click “Generate recommendations”. The tool creates a cut/keep list that includes:

- Vendor name - Current monthly cost - Suggested action (Keep, Cut, or Review) - Reasoning summary (for example, “Low login count, high cost, overlaps with Slack”) - Estimated monthly savings if cut

I can export this list as CSV or copy it to the clipboard for sharing with stakeholders.

Collaborating with ops and finance stakeholders

Sharing the report

I send the cut/keep list to the ops lead and the finance manager via email, attaching the CSV and also providing a link to the live SaaSpend view (the link expires after seven days). In the email I note which items are marked as “Cut” and which need further discussion because they are tied to existing contracts or have compliance implications.

Setting review meetings

We schedule a 30‑minute meeting for each category that has more than two overlapping tools. During the meeting I share my screen, open the similarity table, and walk through the cost‑per‑user numbers. I ask the owners to confirm whether the reported usage matches their experience and to note any special features that are not captured in the feature tags.

Capturing decisions

After each meeting I update the SaaSpend record with the agreed action. If the decision is to keep a tool, I add a note about the reason (for example, “Required for HIPAA‑compliant faxing”). If the decision is to cut, I record the cutoff date and the expected savings. The tool then recalculates the total potential savings and displays a summary banner at the top of the page.

Decision‑support process and confirmation checklist

Reviewing recommendations

Before I act on any cut suggestion, I open the confirmation checklist that SaaSpend generates. The checklist items are:

- Verify that the usage data covers at least the last 90 days. - Check that the tool is not the sole provider for a regulated data flow. - Confirm that the owner has been notified and has acknowledged the notice. - Ensure that any data export or migration plan is documented. - Record the final approval from the finance sign‑off authority.

I tick each box as I complete the corresponding step. The checklist prevents me from missing a critical dependency.

Testing impact in sandbox

For services that provide APIs or user‑generated content, I first create a sandbox instance of the replacement tool (if one exists) and run a parallel test for two weeks. I compare latency, error rates, and user satisfaction scores. If the sandbox shows no degradation, I feel confident proceeding with the cut. I log the test results in the notes field of the SaaSpend entry.

Final sign‑off steps

Once the checklist is complete and any sandbox tests pass, I send a final approval email to the finance controller, attaching the updated SaaSpend report and the signed checklist PDF. After I receive the reply confirming approval, I proceed to cancel the subscription through the vendor’s portal or ask the procurement team to do so. I then update the internal asset register to reflect the change and notify the affected users of the migration timeline.

What this is NOT

No automatic removal

SaaSpend never cancels a subscription on its own. It only presents recommendations and a checklist. The user must manually confirm each action before any change is made to a live contract.

No guarantee of savings

The tool estimates potential savings based on the data provided. Actual savings may differ if usage patterns change, if contractual penalties apply, or if hidden dependencies are discovered later. I treat the numbers as a starting point for negotiation, not as a promise.

Not a replacement for governance

SaaSpend helps surface overlap, but it does not enforce policy, manage approval workflows, or maintain an audit trail beyond the notes I add. I still need our existing SaaS governance process to review security, compliance, and data‑ownership questions before cutting a tool.

Operator checklist for SaaSpend overview

I keep a written checklist next to every release that touches this topic. The list is boring on purpose: name the owner, name the evidence artifact, and name the rollback. If a step cannot produce a file, a ticket, or a log line, it is not a step — it is a wish.

Before you change production

- Freeze the branch or config revision you will measure against. - Record the current failure mode with one concrete input and one concrete output. - Confirm which identity the job runs as, and whether that identity can reach data it should not. - Open the primary references you will cite: https://owasp.org/www-project-top-10-for-large-language-model-applications, https://www.nist.gov/itl/ai-risk-management-framework.

While you run the check

- Prefer one reproducible path over ten anecdotal screenshots. - Write the expected safe outcome before you trigger the tool or query. - Capture the exact command, prompt, schema, or regex under test — not a paraphrase. - If the system can act (send, write, delete, transfer), require a confirmation boundary in the same pass.

After you finish

- File residual risk with an owner and a date, even when the scan is clean. - Do not convert a green check into sales language that claims completeness. - Re-run the same checklist when the model, tool schema, or validation rules change.

Signal | What to record | Stop-ship? Unexpected write or send | Tool name, args, identity | Yes until gated Missing confirmation on destructive action | Call path and bypass | Yes Untrusted text treated as instruction | Source surface and resulting action | Yes for agent reach Scanner clean, judgment open | Deferred items + owner | Only if core path safe

saaspend helps with the measurable first pass. Architecture choices, legal sign-off, and customer-facing claims still need a human owner. Treat every checklist row as decision support, not a certificate.

How I explain limits to buyers

When a prospect asks whether the product "covers everything," I answer with the boundary: automated checks catch known patterns; novel chains and policy judgment still need review. That honesty keeps support load down and keeps the blog aligned with what the product actually does.

If you need a second opinion, pair this write-up with the references below and with your own staging reproduction. Do not skip the reproduction step just because a model wrote a confident summary.

References

- https://owasp.org/www-project-top-10-for-large-language-model-applications - https://www.nist.gov/itl/ai-risk-management-framework