An account map should help someone ask a better question about a company. A neat tree is not enough: if the connecting lines are guesses, the map hides uncertainty instead of explaining the account.
This exercise starts with Forma Labs at forma.example and Maya Chen, VP Sales. Both are fictional fixtures used for this worked example. Vencavo’s data foundation includes 299M+ contact records and 25M+ company records; this exercise does not query those datasets. The output is a small research map and a review worksheet, not a complete team roster, a verified org chart, or an outreach list.
1. Define the question and the input
Our question is: What do we know about the sales function at Forma Labs, and what must we establish before choosing a conversation partner?
The sample supplies a company name and domain, plus Maya’s role, Sales department, and VP seniority. It also supplies a fictional work email and an illustrative phone-availability flag. Those contact illustrations do not establish a reachable person or permission to contact anyone.
Write down the intended company first. If a name search returns several similar companies, resolve the identity before attaching a person. In this fixture, the reserved domain joins Maya to Forma Labs. A real implementation would need a defined entity-resolution policy; the sample domain is not a released production ID.
The useful input is deliberately small. You do not need to fill a page with people before the map can expose what is missing.
2. Separate the nodes from the claims
Create four concepts rather than storing everything inside one person label:
| Concept | Supplied in this example | What it does not establish |
|---|---|---|
| Company | Forma Labs · forma.example | A parent company, subsidiary structure, or complete legal identity |
| Person | Maya Chen | A unique production identity or verified contact |
| Role | VP Sales · Sales · VP | Budget ownership, decision authority, or a manager |
| Company membership | Maya is linked to Forma Labs in the fixture | Employment dates, tenure, or a complete department roster |
The data model shows a proposed way to join these concepts with explicitly illustrative local IDs. Those JSON objects explain a design; they are not live API responses or identifiers to send to an endpoint.
Keep a claim beside the connection it supports. The fictional fixture supports the demonstration membership. It does not support every line that would make a familiar-looking corporate tree.
3. Draw the smallest honest map
For the worked example, place Forma Labs next to Maya’s supplied role context. Label the connection as a fictional company membership. Show Sales as the supplied department and VP as seniority.
Then leave the manager connection unknown. Do not add a chief executive, a sales director, or another colleague simply to give Maya a parent node. We have no such person in the Forma fixture. Do not interpret the absence of those nodes as evidence that the roles do not exist.
A useful handoff might say:
Maya Chen is the fictional VP Sales associated with Forma Labs. Sales and VP describe the supplied function and role level. Her manager, team members, purchasing responsibilities, and tenure are not supplied. The next research step is to establish the relevant team structure and responsibilities from attributable evidence.
This is enough to orient the next reviewer without claiming a verified hierarchy.
4. Decide what each connection permits
Use a review decision rather than a confidence-looking number that has no measured basis:
| Candidate conclusion | Decision | Next action |
|---|---|---|
| Maya is associated with Forma Labs in this exercise | Retain as a fictional membership | Keep the sample label attached to the claim. |
| Maya belongs to the Sales function | Retain the supplied department | Do not infer the department’s size or roster. |
| Maya reports to a particular executive | Leave unknown | Seek evidence for that specific relationship. |
| Maya owns a purchase because she is a VP | Do not infer | Establish the responsibility for the actual problem. |
| Maya’s promotion changed her manager | Leave unknown | Review role change and reporting relationship separately. |
Company membership and a reporting edge answer different questions. A production reporting edge would require identified people or memberships, a defined direction, and evidence attributable to that relationship. Sharing a department or appearing beside someone on a chart is insufficient.
5. Work through the worksheet
Download the account/org mapping worksheet. It includes Maya’s company membership, department and seniority as fictional supplied context, plus unresolved reporting and buying-responsibility rows. No managers, production source links, or dates have been invented.
For each row, review the relationship kind before entering a related person. Keep source_reference, observation and verification dates blank until you actually have the relevant evidence; blank cells in this authored worksheet mean not supplied. A field’s presence in a spreadsheet does not make the evidence exist.
Record one next action and a review owner. If later evidence conflicts, preserve both claims and their references rather than silently choosing the one that creates the tidiest chart. Add a reporting connection only after the specific edge is supported. Never turn an empty related-person cell into a synthetic contact.
6. Hand off the map with its limits
A reviewer should be able to identify the company, distinguish supplied membership from inferred authority, and locate the unresolved connections without reading a chat transcript. Include the review decision and next action alongside the map.
Continue with the org-chart example and people model. If a role changes, use the role-change interpretation guide before updating relationships. The field-provenance guide explains how to retain evidence when values disagree. For data-access questions, contact [email protected]. The worksheet and examples remain fictional; they do not connect to a live API, MCP server, or automated relationship-update service.