Anonymized. Brand names and niche vendors generalized; the architecture is as mapped.
When a company grows by adding brands, the tech stack grows by accretion. Each brand picks what it needs; nobody draws the whole thing. The symptom is a question that should be simple and is not: "if a candidate fills out the form on brand A's site, where does that record end up?" This group could not answer it without three people on a call.
The map
The diagram below is the deliverable. Brands on the left, tools grouped by who uses them, and every connection drawn with a line style that says what kind of relationship it is.
How to read it
| Line style | Meaning |
|---|---|
| Thin, brand-colored | Ownership: this brand uses this tool |
| Bold, brand-colored | Active data integration between two systems |
| Thickest | An automation bridge (here, the contact form routed through Zapier) |
| Amber | In-progress enablement |
| Red, dashed | Not integrated: a data silo or a manual process |
What the map made obvious
- Three job boards feed nothing. Indeed, ZipRecruiter, and Monster were each in use and none were connected to the applicant tracking system. Every applicant from those sources was handled by hand or lost.
- The ATS and the payroll/placement system do not talk. A placement recorded in one has to be re-keyed in the other. That is a silo with a direct cost in hours and in reporting accuracy.
- Two CRMs by design, not by accident. Brands A and B run on the ATS; brand D runs on HubSpot. The map showed that this is fine as long as the shared tools (ZoomInfo, the AI assistant) are explicitly connected to both, which they now are.
- One automation bridge carries the website. The contact form on the agency-hosted sites reaches the ATS only through Zapier. That is acceptable, and it is also a single point of failure that should be documented and monitored.
- Email from the ATS was half-enabled. The Outlook gadget and ATS-for-email were in progress. Drawing them in amber put a name and a status on something that had been "almost done" for a while.
What came out of it
- A gaps-and-actions list, ranked. Each red line became a row with the current state, the desired state, a priority, and an owner column. The ATS-to-payroll silo was marked the highest architectural risk in the stack.
- A tool inventory that lives beside the map. Every tool with its category, the brands it serves, integration status and partners, its purpose, and where the admin and documentation live. The map and the inventory now change together.
- The automation bridge recorded as an integration in its own right. A Zapier flow that carries every website inquiry is infrastructure, not a convenience, and it is now listed and versioned like one.
How to build your own
- List every tool with its owner and which business units use it. Expect to find two or three nobody remembers buying.
- Draw brands or business units on one side and tools grouped by who shares them.
- Draw every connection, and be honest about the ones that do not exist. The red dashed lines are the point of the exercise.
- Keep it as a living document. Version it; date it; re-check it whenever a contract renews.
The diagram is built in plain-text Mermaid, so it lives in version control and re-renders when the stack changes. A whiteboard tool works too. What matters is that one picture exists and someone owns it.
Want this done in your instance? Most engagements start with an audit.
Book an intro call →