Uncovering Unofficial Tool Dependencies: Find the Spreadsheets Your Solution Must Replace

The architecture diagram the prospect shares shows their official systems. It does not show the spreadsheet a team lead updates every Monday, the script someone wrote years ago that reconciles two databases, or the shared mailbox that acts as an approval queue. Yet those unofficial tools are often what keep the business running, and they are invisible until your implementation switches something off and a team cannot do its job.

Uncovering unofficial tool dependencies is the discovery skill of identifying the undocumented spreadsheets, scripts and informal utilities that end users rely on to do their work. Find them in discovery, and they become requirements. Miss them, and they become escalations after go-live.

The problem it solves

• The need: stated requirements describe the official process; real requirements include the workarounds people built around it.
• Who faces it: SEs scoping a solution that replaces or touches existing workflows, and the post-sales teams who inherit the scope.
• Stage: discovery and solution scoping, before sizing and before the proposal.
• Decision it supports: what must be replaced, integrated or deliberately retired, and what that adds to scope.
• Success looks like: a short inventory of unofficial tools, each with an owner, a purpose and a decision.

Why buyers do not mention them

Unofficial tools are rarely hidden on purpose. Managers may not know they exist. Users may assume they are too small to matter, or worry that admitting to them reflects badly on the team. Some exist precisely because an official system failed, which makes them politically sensitive. Your questions need to make it safe to talk about them.

How to surface them

Ask about the moments, not the tools

“What do you open first on a Monday morning?” “Where do you check before you approve something?” “What do you keep for yourself that is not in the system?” Questions about routines reveal tools that a question about systems never will.

Ask to watch, not just to hear

If the prospect agrees, ask a frontline user to walk through a typical task on screen. Exports, copy-and-paste steps and side files show up within minutes.

Follow the exports

Ask which reports are exported regularly and where the exported files go. An export that feeds a spreadsheet that feeds a decision is a dependency.

Normalise it

Say it plainly: “Every team I work with has a few home-grown tools that keep things moving. Which ones does yours rely on?” Normalising the question removes the embarrassment.

Capture each tool in one line

For every unofficial tool, record: what it is, who owns it, what it does, how often it runs, what breaks if it disappears, and your proposed decision: replace (the solution covers it), integrate (keep it and connect it), or retire (agreed no longer needed). An unknown decision is fine at first; an unrecorded tool is not.

Adjusting to the situation

• Frontline users who fear automation: their tools represent expertise. Present the inventory as protecting what they built, not exposing it.
• An executive briefing on vendor consolidation: unofficial tools are hidden spend and hidden risk; summarise the count and the risk, not the individual files.
• A regulated environment: unofficial tools that hold sensitive data are a compliance exposure. Flag them carefully and let the prospect decide how to raise them internally.
• A merger of two stacks: each side has its own unofficial layer. Inventory both before planning consolidation.
• A prospect burned by unused software: unofficial tools often explain why the last solution was not adopted: it did not replace them.

Common mistakes

• Treating every spreadsheet as a problem to remove. Some are the right tool and should stay.
• Promising the solution replaces a tool before checking what it actually does.
• Collecting the inventory and not passing it to the implementation team.

How you know it worked

• You have an inventory with an owner and a decision for each tool.
• Your scope and sizing reflect the tools marked “replace” or “integrate.”
• No unofficial tool appears for the first time after contract signature.

Where this skill sits in the deal

Upstream: current-state workflow mapping shows where data leaves the official systems. Parallel: surfacing integration touchpoints covers the official interfaces while this covers the informal ones. Downstream: the inventory belongs in scoping and sizing, in technical contract review, and in the handoff to implementation.

Practice it before the live call

Getting people to talk about the tools they are slightly embarrassed by is a human skill, not a product skill: part of the 80% of Solution Engineering. SE Ignite teaches discovery techniques like this as free, tech-agnostic micro-skills you can rehearse before using them with a real buyer.