Organizational Network Analysis (ONA) Survey Template
Send this Organizational Network Analysis (ONA) survey to map how work actually gets done: who people rely on for advice, problem-solving, approvals, and information. You will get a practical view of bottlenecks, connectors, and cross-team gaps, plus safe defaults for roster setup, nomination caps, and reporting rules. Use the included copy/paste launch and consent language to set clear expectations: confidential, system-improvement focused, and not for performance evaluation.
Trusted by 5000+ Brands
When to Run an ONA Survey (3 best moments)
After a reorg or merger
Outcome: You will see whether the new structure is actually creating the cross-team ties you expected (or accidentally cutting them). Default (safe): Run a full ONA 6-10 weeks after the change, once the dust settles. Customize if: If teams are still moving daily, run a smaller, program-bounded map first and expand later.
Decisions it unlocks: Where to add explicit handoffs, shared forums, onboarding buddies, and backup owners for critical work.
When delivery is stalling across functions
Outcome: You will spot where work is getting stuck (approvals, dependency handoffs, overloaded go-to people). Default (safe): Include an approvals/decisions module plus tie-strength (frequency + criticality). Customize if: If the problem is confined to one value stream, scope the boundary to that stream and its upstream/downstream partners.
Decisions it unlocks: Which approval steps to remove, who needs delegated authority, and where to rebalance load or add backups.
When remote/hybrid work is creating invisible silos
Outcome: You will find who is out of the loop and which groups are not getting timely access to information and decision-makers. Default (safe): Add one inclusion/access prompt (missed loops) and segment results by location/time zone/role type. Customize if: If psychological safety is fragile, avoid sharing any identifiable maps and report only at higher-level aggregates.
Decisions it unlocks: Where to fix comms cadence, meeting invites, community channels, and cross-site pairing to improve access and belonging (common use cases summarized in Frontiers in Psychology review of ONA and inclusion/belonging).
ONA Survey Questions to Include (with safe defaults)
"List up to 8 people you go to for advice or problem-solving when you are stuck."
Why it matters: Outcome: You will map the real problem-solving network (who helps unblock work). Default (safe): Roster-based picker + cap at 8 to keep effort reasonable and stop "everyone" lists (a common design choice in survey-based network collection; see Collecting survey-based social network information in work organizations). Customize if: If you are mapping across partners/vendors, allow a limited "type a name" option for external contacts.
When to use: Include in every full ONA run. Trend this over time to see if interventions spread expertise and reduce single points of failure.
"For each person you listed for advice/problem-solving, how often do you rely on them?"
Why it matters: Frequency separates one-off help from repeated dependency. Use this to spot overload risk and to prioritize fixes.
When to use: Ask as a follow-up grid after each tie list. Default (safe) scale: "0 times in the last 2 weeks / 1-2 / 3-5 / 6+" (or "Monthly / Weekly / Several times per week / Daily" if you run monthly).
"When you need a decision or approval to move work forward, who do you typically go to? (Select up to 5.)"
Why it matters: This identifies the decision-rights path people actually follow, not the org chart. A tight cluster around one or two names is a bottleneck signal.
When to use: Use when cycle time is slow, quality gates are unclear, or rework is high. Default (safe): Cap at 5 (approvals networks should be smaller than advice networks).
"For each person you listed for approvals/decisions, how often does work wait on their input?"
Why it matters: Waiting time is the operational signal. Pair this with frequency to find where delegation, clearer decision rights, or queue management will pay off.
When to use: Use as a follow-up to the approvals list. Default (safe) scale: "Never / Sometimes / Often / Almost always" (keep it short so people answer).
"Who keeps you informed about changes that affect your work (priorities, decisions, process updates)? (Select up to 8.)"
Why it matters: Information flow is where hybrid and matrixed orgs break quietly. This shows who acts as a hub and which groups are not connected to timely updates.
When to use: Include in org-wide ONA or any transformation program with heavy change communications. Default (safe): Cap at 8 and segment by location/time zone.
"How responsive is each person you listed when you reach out?"
Why it matters: Responsiveness helps you distinguish "popular but overloaded" from "popular and effective." It also flags where process fixes (intake, office hours, documentation) could reduce pings.
When to use: Use as a follow-up tie-strength item across modules. Default (safe) scale: "Very unresponsive / Unresponsive / Neutral / Responsive / Very responsive."
"Who do you consider a go-to subject matter expert (SME) for [topic/program]? (Select up to 5.)"
Why it matters: This builds an expertise directory based on real behavior, not self-report. It also spots fragile areas where critical knowledge sits with one person.
When to use: Use for bounded topics (security, pricing, data, product domain). Default (safe): Ask per topic and keep the cap at 5; rotate topics across quarters instead of asking all at once.
"In the last 4 weeks, were there times you were left out of a conversation or decision that affected your work?"
Why it matters: This is your inclusion/access tripwire. It surfaces where loops are closing without the right stakeholders, even if the network map looks dense.
When to use: Add when you are explicitly studying belonging, remote/hybrid inequities, or cross-site access. Default (safe): "Yes/No" + optional comment (do not require names).
"(Optional pulse add-on) I know who to go to when I need help to move my work forward."
Why it matters: This gives you a quick outcome read without changing the network questions. Keep it clearly labeled as an add-on so your ONA results stay comparable run-to-run.
When to use: Use in a short follow-up pulse after you change decision rights, improve onboarding, or stand up SME office hours. Default (safe): 5-point agreement scale + one open comment.
- Context fields (keep short): team/function, role type (IC/manager), location/time zone, tenure band, optional program membership.
- Watch out: Do not add 20+ engagement items to a network run. If you want attitudes, run a separate survey or keep the pulse add-on to 2-4 items max.
How to Scope and Deploy an ONA Survey in 7 Steps (plus customization and comms copy)
-
Step 1: Define the network boundary (who is in/out)
Outcome: Your roster and reporting cuts match the real work system. Default (safe): Include everyone who is required for the workflow (employees + long-term contractors) and exclude short-term/occasional contributors. Customize if: If work crosses business units, include the top 1-2 adjacent groups that most often show up in nominations.
- Do: Write a one-paragraph scope note and share it with sponsors before launch.
- Do: Document edge cases (contractors, interns, shared services, multi-team staff) using sampling and defining your in-scope network boundary.
- Watch out: If you exclude a key group, your map will over-credit the remaining connectors because missing ties get forced through whoever is left.
-
Step 2: Choose roster vs open name entry
Outcome: You avoid duplicate names and you can segment results cleanly. Default (safe): Use a roster with unique IDs, searchable names, and team grouping. Customize if: If you are mapping cross-boundary ties (customers, partners), add a controlled "Other (type name/organization)" field.
- Do: Use one canonical display name per person (avoid nicknames as separate entries).
- Do: Add a "primary team" field and allow a "secondary team" option for matrixed roles.
- Watch out: Open entry creates spelling variants and duplicates that take hours to clean.
-
Step 3: Set nomination caps and tie-strength scales
Outcome: You capture the strongest, most operationally relevant ties without fatigue. Default (safe): Advice/problem-solving cap 8; information cap 8; approvals/decisions cap 5; SME-by-topic cap 5. Customize if: If roles legitimately depend on many people (e.g., service desk), raise caps for that subgroup only.
- Frequency scale (copy-ready): "0 / 1-2 / 3-5 / 6+ times in the last 2 weeks."
- Criticality scale (copy-ready): "Not critical / Somewhat critical / Critical" (short scales often improve completion).
- Watch out: No cap + long scales = "everyone-to-everyone" noise and drop-offs.
-
Step 4: Configure branching and subgroups (manager vs IC, programs)
Outcome: You ask only what each person can answer well. Default (safe): One core ONA for everyone + 1-2 optional modules for specific populations (people managers, program members). Customize if: If you need a pulse, drop to one tie type plus one tie-strength item.
- Do: Keep the core map consistent across runs so you can compare over time.
- Do: Label add-ons as "Optional pulse" so people understand the purpose.
-
Step 5: Pretest with 8-15 people and fix the roster
Outcome: You catch roster gaps, confusing wording, and excessive effort before the full send. Default (safe): 20-minute pretest with a mix of teams/levels/time zones. Customize if: If your org uses many similar names, add photos or unique identifiers (department, location) to the roster display.
- Do: Ask testers to name 3 people and confirm they can find them quickly.
- Watch out: If finding names is hard, response rate drops fast and nominations skew to "top of mind."
-
Step 6: Run fieldwork for 2-3 weeks with a reminder cadence
Outcome: You get enough coverage to trust the shape of the network. Default (safe): 14-21 days live, with 2-3 reminders (Day 4-5, Day 10-12, 48 hours before close). Customize if: If a critical team is below target mid-field, send a targeted reminder from their leader.
- Internal starter target: Aim for about 80% overall, then adjust after you see your baseline; always check coverage by team/role because missing data can distort networks (see Effects of missing data in social networks).
- Do: Track and address nonresponse and response bias; response rate alone does not guarantee low bias (see Groves 2006 on nonresponse rates vs nonresponse bias).
- Watch out: Do not close the survey with one function at 40% while others are at 90%; you will misread cross-team ties.
-
Step 7: Define success checks before you look at the map
Outcome: You avoid false precision and you know what is safe to share. Default (safe): Set response, completeness, and reporting thresholds in advance. Customize if: If you must report small specialties, roll them up or use qualitative follow-ups instead of publishing small-group network views.
- Response rate definition: Use a consistent calculation (AAPOR provides standard outcome-rate definitions in Standard Definitions).
- Completeness checks: % who made at least 1 nomination per module; median nominations per respondent; drop-off by page.
- Watch out: If one subgroup has low completion, treat their network pattern as "unknown" and fix fieldwork next run.
Subject: 10-minute collaboration map: help us reduce bottlenecks
Body: We are running a short Organizational Network Analysis (ONA) survey to understand how work and information really flow across [org/team]. You will be asked to select up to [cap] people you go to for advice, approvals, and key updates. Results will be reported in aggregate to improve systems (handoffs, decision rights, resourcing), not to evaluate individual performance.
Time: About 10 minutes. Close date: [date]. Confidentiality: Your responses will be handled confidentially and shared only in groups large enough to protect individuals. Thank you for helping us remove friction.
Purpose: This survey maps collaboration and information flow so we can reduce bottlenecks and strengthen cross-team work.
Confidentiality (what we promise): Your individual responses will be kept confidential. Only the survey admins/analytics team can access raw responses. We will report results in aggregate and suppress small groups.
Limits (say this plainly): We will not use this survey for individual performance evaluation. We will not share identifiable network maps for small teams. For details on handling and access controls, use privacy, confidentiality, and data handling basics.
- Ready to ship: boundary written down, nomination caps set, consent text pasted.
Roster vs Open Name Entry (and Full ONA vs Pulse)
| Decision factor | Roster-based name selection (recommended default) | Open name entry (type a name) |
|---|---|---|
| How to decide | Outcome: clean, analyzable ties. Default (safe): use a roster with unique IDs and team fields. Customize if: add limited open entry only for external contacts. | Outcome: captures out-of-roster ties. Default (safe): avoid for internal-only mapping. Customize if: use when the boundary is truly unknown or cross-company. |
| Data cleanliness | High (no duplicates; consistent identifiers). | Lower (spelling variants and duplicates require cleanup). |
| Respondent effort | Lower (searchable list; faster completion). | Higher (typing names slows people down). |
| Bias risk | Lower recall burden; people can find less-salient ties. | Higher recall burden; "top of mind" nominations dominate (see discussion of survey-based network collection tradeoffs: Collecting survey-based social network information in work organizations). |
| Handling duplicates | Built-in via unique IDs. | Manual dedupe needed (John Smith vs Jon Smith). |
| Privacy considerations | Easier to enforce reporting thresholds by subgroup. | Harder to manage if people type identifiable details (clients, sensitive roles). |
| Best fit | Bounded org/team/program; repeated runs; segmentation needed. | Cross-boundary mapping; early discovery when you cannot build a roster yet. |
| Choice | Full ONA (map) | ONA pulse (track one outcome) |
|---|---|---|
| Default setup | 3 tie types (advice + approvals + info) + 1-2 tie-strength items; 10-15 minutes. | 1 tie type + 1 tie-strength item (or 2-4 pulse outcomes); 3-6 minutes. |
| Cadence | Run around major change (reorg, merger, operating model shift). | Run 4-8 weeks after a specific intervention (decision rights change, SME office hours). |
| What you can conclude | Where bottlenecks, bridges, silos, and single points of failure sit across groups. | Whether a targeted pattern moved (e.g., fewer "work waits on approvals"). |
| What you cannot conclude | Individual performance or intent. | Org-wide network shifts (you are not measuring the full map). |
| Watch out | Do not add large attitude batteries; it dilutes the map and increases drop-off. | Do not compare pulse results to a prior full map unless the question wording and roster boundary match. |
Interpreting ONA Results and Turning Them Into Action (without ranking people)
-
Start here (safe defaults): Outcome: you will turn patterns into fixes, not a list of "top people." Default (safe): report in aggregate, suppress small groups (e.g., n<=5), and state "not for performance evaluation" in every readout. Customize if: if your org is small, roll up to higher-level groupings and share only system themes.
-
Connectors (many people go to them): What you will see: a few names repeatedly nominated for advice or information (high in-degree centrality; see Freeman 1978 on centrality). What to do next: add office hours, improve documentation/FAQs, rotate "on-call" support, and create backups so the connector can take PTO without stalling work (a common ONA takeaway in practice; see Cross and Prusak, Harvard Business Review).
-
Bridges (the link between groups): What you will see: one person (or a tiny set) connecting two functions/sites. What to do next: formalize the interface (shared channel, weekly triage, defined handoff), and train a second bridge so cross-team work does not depend on one relationship (bridging positions are a known advantage point in org networks; see Burt on brokerage and social capital).
-
Bottlenecks/overload risk (work waits): What you will see: high nomination counts plus high "work waits on them" or low responsiveness ratings. What to do next: change decision rights, create clear approval criteria, add delegation rules, or split the queue by topic so work does not stack on one role.
-
Silos (few cross-team ties): What you will see: dense ties inside teams, sparse ties across teams or locations. What to do next: set up cross-team pairing for shared work, introduce structured handoffs, and add recurring cross-functional forums tied to real workflows (not status meetings).
-
Single points of failure (critical expertise concentrated): What you will see: one SME nominated as "critical" by many. What to do next: create a backup SME plan, record walkthroughs, add runbooks, and time-box direct help with an intake form so knowledge gets captured.
-
Share results responsibly (do/don't): Do publish themes + aggregated patterns, and follow sample size and minimum reporting thresholds for subgroup cuts. Don't email identifiable network diagrams to broad audiences, especially for small teams. Watch out: a "most-nominated" list turns a system diagnostic into a popularity ranking.
- Ready to act: pick 1-2 patterns to fix, assign an owner, and set a follow-up pulse date.
Frequently Asked Questions
Is an ONA survey anonymous or confidential?
Anonymity means nobody (including admins) can link responses to a person. Confidentiality means admins can access raw data, but you restrict access and report only aggregated results. For ONA, promise confidentiality with clear limits: suppress small groups (e.g., n<=5), restrict raw-data access, and do not share identifiable maps broadly.
Roster-based or open name entry: which should I choose?
Choose roster-based when you can define the in-scope group and you need clean segmentation by team, level, or location. Choose open name entry only when the boundary is truly unknown or cross-company (partners, clients), and plan time for deduping. A searchable roster with unique IDs is the safest default for repeatable results.
How many people can someone nominate (and why cap it)?
Set a cap so you capture the most important ties without fatigue or "everyone" nominations. A practical default is 8 for advice/information ties and 5 for approvals/SME-per-topic, then adjust only for roles that genuinely depend on many people. Caps also make comparisons fair because everyone answers under the same constraint.
What response rate do we need for ONA to be useful?
Internal starter target: aim for about 80% overall, then adjust after you see your baseline, and always check coverage by team and role. Missing nodes can bend the shape of the network (see Effects of missing data in social networks), and response rate alone does not guarantee low bias (see Groves 2006). If a key group is low mid-field, extend the window and send targeted reminders from that group's leader.
Can we use ONA to evaluate individual performance?
No. ONA shows relationships and workflow paths, not performance quality or intent, and it is easy to misread popularity as value. Use ONA to improve systems (handoffs, resourcing, decision rights, knowledge access) and pair it with other inputs if you need performance evaluation.
How often should we run an ONA survey?
Run a full map around major changes (reorg, merger, operating model shifts) or when delivery is consistently stalling across functions. Between full maps, run narrow pulses that track one targeted outcome (for example, approvals bottlenecks) so you avoid survey fatigue. Communicate what changed because of the last run before you ask people to participate again.
Related Survey Templates
FREE TO START -- NO CREDIT CARD REQUIRED