A useful relationship record connects the relevant history of a person or organization without erasing who said what, when it happened or who may see it. Start with the relationship you need to manage, choose a stable identifier, and attach authorized interactions as dated records. Then prepare a short, source-linked brief of current commitments, questions and changes. A record is useful when the next colleague can understand the situation and follow through without rebuilding it from messages.
This lesson is for membership, partner and customer teams preparing a handoff or recurring review. You will produce a record plan and a one-page relationship brief. It does not require scoring people or collecting every interaction they have with your organization.
- Define the decision and whose relationship the record describes.
- Separate people, organizations and dated interactions.
- Choose a small shared core and preserve local detail.
- Review themes, commitments and changes against their sources.
- Prepare a dated brief with an owner and next action.
- Check access, corrections and the next refresh.
Whose record are you building?
An organization and its current representative are different entities. Give each a continuing identifier and record their relationship, including dates when a representative changes. Otherwise a new representative can appear to have made the previous representative’s commitments, or a change of contact can look like a change in the organization’s views.
In a fictional network, Organization Cedar has identifier O-14. Ana represents it until June; Lee takes over in July. Cedar’s annual return belongs to the organization and reporting period, with the submitting person recorded. Ana’s individual event feedback remains Ana’s response. A handoff note identifies which organizational commitments remain open and who has authority to confirm them.
Define the matching rule before importing data. A name or shared email address alone may be insufficient. Keep uncertain matches in a review queue rather than automatically combining records. Retain the source identifier so a correction can be traced.
What should the shared record contain?
Keep stable profile information separate from observations and interactions. Reuse appropriate registration information instead of asking for it on every survey. Confirm changing details at a useful interval and retain effective dates when those changes matter to analysis.
| Record layer | Example | Why it stays separate |
|---|---|---|
| Organization or person profile | Identifier, current region, role | A changed role should not overwrite who contributed an earlier response. |
| Relationship | Representative of O-14 from July | One person may represent more than one organization over time. |
| Interaction | September survey, call note or uploaded return | Each has its own date, source, author and permitted audience. |
| Commitment | Send revised guidance by 12 September | A promise needs an owner, due date and completion evidence. |
Local teams can use different forms. Agree only the fields needed for the shared purpose, then map compatible fields in the data dictionary. A local “visit” and a local “meeting” are not automatically the same interaction type. Document the mapping and leave unmatched detail available in its original context.
How do you make qualitative history usable?
Use a small codebook to organize recurring subjects, such as access problems, support requests or upcoming priorities. Keep the original passage, source date and reviewer decision beside the code. A theme does not need a numerical score. If a rubric is useful, define its anchors and test it before using its ratings.
Distinguish a contributor’s statement from a staff interpretation. “We cannot attend on Tuesdays” is a stated scheduling constraint. “The member is disengaged” is an interpretation requiring further evidence. Do not let a summary turn the first into the second.
Older evidence also needs context. A complaint marked resolved in August should not appear as a current unresolved issue in September merely because its original wording is still in the history. Keep the earlier event and the later resolution; show the current status with its basis.
What belongs in the one-page brief?
Prepare the brief for a named purpose and date, using only the records authorized for that audience. Include the current relationship context, recent changes, open commitments, unresolved questions and the next action. Link each substantive statement to the relevant evidence. State uncertainty where sources disagree.
| Brief item | Fictional example |
|---|---|
| Purpose and scope | Prepare Cedar’s September service review; records available through 5 September. |
| Current context | Lee is the current representative; July registration update. |
| Open commitment | Central team agreed to send guidance; August meeting note, not yet confirmed delivered. |
| Question to verify | Does the new meeting time work? No response recorded. |
| Next action | Account owner confirms delivery and asks about the proposed time. |
Save the reviewed brief with its source cutoff and revision date. Source citations improve traceability but do not guarantee identical AI wording on a later run. Preserve approved outputs when they support a decision, along with the underlying evidence and review history.
How does this work in Sopact?
You can begin with linked tables and a manually written brief. Repeated exports become difficult when the same relationship receives surveys, documents and notes across several cycles. The Sopact approach is to connect those inputs to continuing records and supply the relevant definitions and context for analysis.
Test the configured workflow with one relationship: can a reviewer reach the source, distinguish a proposed action from a completed one, correct a mistaken match, and restrict the brief to its intended audience? People confirm commitments and decide what to share. Replacing names with identifiers does not by itself make detailed relationship history anonymous.
Practice: prepare a handoff another colleague can use
Choose a fictional or authorized relationship with three interactions. List the entity and source identifiers, dates and access scope. Write a five-line brief. Ask a colleague to trace every line, identify the next action and explain what remains unknown. Revise any line that depends on your memory rather than the record.
Frequently asked questions
Does every interaction belong in the record?
No. Include what serves the defined relationship purpose and is appropriate to retain and use. Private or unrelated material should not be added merely because it is available. Record the intended audience and retention approach before connecting sources.
Do we need a score for each theme?
No. Themes, requests and commitments can be useful without scores. Use a rating only when it supports a decision and has a defined rubric. Keep the evidence and reviewer interpretation separate so a reader can question the conclusion.
Can we combine everyone who uses one organizational email?
Not automatically. A shared inbox may represent several people or changing representatives. Use an organizational identifier and record the actual contributor when known. Review ambiguous matches before combining histories.
What happens when profile details change?
Update the current profile and preserve effective dates where the change affects interpretation. A later region or role should not silently replace the context of an earlier response. Decide which fields need history based on the questions you will answer.