Team invites can add useful context to a PQL review when you distinguish invitations, accepted membership, and meaningful shared use. Keep the workspace ID as your grouping key, inspect who actually joined, and use professional context where it helps. An invite count or job title alone does not establish buying intent or authority.
Which invitation event matters?
Start with the event that changes participation in your product.
A sent invite can expire or be ignored. An accepted invite creates membership. An accepted member completing a shared task creates product evidence. Track those states separately rather than scoring every email in the invitation table as a new stakeholder.
| Observed event | What it supports | What it does not prove |
|---|---|---|
| Invitation sent | Someone tried to share or collaborate | That the invitee joined or will buy. |
| Invitation accepted | The person joined this workspace | That they used the product or own a budget. |
| Accepted member uses a shared workflow | The product is being used collaboratively | That a paid rollout is agreed. |
| Member requests a commercial capability | A specific need worth reviewing | That company size determines seats or deal value. |
For products built around sharing links with clients, invite behavior may describe distribution rather than team adoption. Use the event semantics of your own product.
What should the workspace review sheet contain?
Combine first-party workspace evidence with bounded professional context.
Copy these columns into a review sheet:
- Workspace ID and existing account owner.
- Invitation time, acceptance state, and member ID.
- Relevant product actions by accepted members.
- Known identifier available for a person lookup.
- Returned current title or employer context, when present.
- Missing or disputed role information.
- Review reason, next action, and review outcome.
These are proposed workflow columns, not EnrichLoops response keys. Your product determines membership; enrichment describes professional context for supported identifiers.
When is a person lookup useful?
Use it when professional context changes a real review and the identifier is supported.
A work email or LinkedIn profile URL can support known-person enrichment. Personal or role addresses are not a promised person-match path. A profile URL can be useful when the member uses a personal address, if you already hold that professional identifier.
A person result's current position can include a title and employer name. The matched company object can be null, and employer domain is not guaranteed. Full company fields require a separate supported company request. See the people documentation.
Do not call an inferred department, buying role, or decision authority an API field. If you assign a role label yourself, keep the basis and an Unknown choice.
How should the review trigger work?
Trigger on a meaningful change, then update an existing account review instead of creating repeated alerts.
For an illustrative policy, review an account when an accepted second member completes the shared activation milestone. Also allow an explicit request for a commercial feature to create a review.
A title can inform the handoff, but it should not force a sales assignment by itself. Respect the existing account owner and let missing company context remain unknown.
The review should answer: what changed, which accepted members participated, what they did, what context is known, and what help could be useful next. Use a defined review deadline and deduplicate repeated events under your own policy.
What does a worked workspace example look like?
Show accepted participation before making the commercial interpretation.
In this fictional example, one founder creates a workspace. Four work-email colleagues and one personal-email colleague are invited. Three work-email colleagues accept and complete a shared setup milestone; the others have not used the product.
The review says “three additional accepted members completed shared setup,” not “five new members of a buying committee.” The founder remains the known contact until the team confirms roles.
For an illustrative enrichment budget, assume the founder and three accepted work-email members all return successful person results, and one confirmed company request succeeds:
| Operation | Successful requests | Credits each | Credits |
|---|---|---|---|
| Founder work-email person lookup | 1 | 3 | 3 |
| Three accepted work-email members | 3 | 3 | 9 |
| Confirmed company lookup | 1 | 1 | 1 |
| Reuse the saved company result | No new request | 0 | 0 |
| Total | 13 |
Reusing the saved company result causes no new request. Submitting another successful company lookup would cost another credit. This arithmetic assumes the stated successes, not a guaranteed match rate. The task and credit documentation gives the operation rules.
What should you validate before automating reviews?
Check participation, account identity, role limits, and alert duplication.
Test a pending invite, an accepted inactive member, an active member, a reinvite, and a member in multiple workspaces. Confirm each belongs to the correct workspace and that repeated events update the existing review appropriately.
Review any inferred role labels with the team. Preserve Unknown instead of forcing every title into a sales-friendly category. Compare review outcomes over time before assigning numerical weights to invitation patterns.
Evaluate known-person context on a small permitted sample, then compare it with accepted workspace activity before automating reviews.