Hemory TeamOn this page
Someone proposes routing support tickets by specialist skill instead of sending them to the general queue. A colleague says, “We tried that last year. It didn’t work.” Before dropping the idea—or repeating the same test—you need to know what actually happened.
Recover the trial’s scope, evidence, and limitations. A discussion can explain why an idea was explored; a trial log or work record can establish whether it ran and what was observed. Hemory helps retrieve captured background, so the next attempt can build on earlier learning rather than a vague verdict.
Establish whether the idea was actually tried
An old mention of an idea is not evidence of an experiment. Separate the stages before looking for a result.
| What you find | What it establishes |
|---|---|
| A suggestion in a meeting | Someone proposed the approach |
| Agreement to prepare a trial | A next step was accepted; execution is not yet established |
| A trial record or confirmation of execution | The approach was tried within the recorded scope |
| Observations or measured results | Evidence about what happened during that attempt |
| A decision to continue, change, or stop | The next choice, with its stated reason if recorded |
Use this distinction to narrow the search. If the records show only a proposal, the useful question is whether a trial ever followed. Searching indefinitely for a failure report assumes a result that may not exist.
Recover the question and scope of the original trial
Locate the relevant Hemory discussion and use conversation Q&A to ask:
What problem was the specialist-routing trial intended to address, and which teams or ticket types were included?
The original wording may differ from today’s proposal. “Expert queue,” “skills routing,” and “specialist assignment” could refer to the same trial. A similar name could also describe a different version. Use the relevant period, team, or operational problem to distinguish them.
Capture the scope that affects interpretation: location, participants, ticket types, duration, and any relevant staffing or process conditions. Record only what the sources establish; an unknown detail should remain a question.
Hemory can retain the explanation that did not make it into a short project note. A comment about specialist availability may become important when someone later proposes the same routing rule under a different staffing arrangement.
Find evidence of execution and outcomes
Use the appropriate work records to establish what ran. They might include a trial log, a configuration change record, an operational report, or a clear account from the people involved.
Keep observations separate from explanations. “Some billing tickets waited until the next morning” describes what was reported. “Specialist routing caused every delay” is a broader conclusion requiring additional evidence.
If a conversation contains a verbal result report, identify it as such. It can be useful, but it should not silently become a measurement from a dataset. When records conflict or comparisons are unclear, preserve the narrow finding and identify what cannot be concluded.
A completed example: the specialist-routing pilot
Here is a fictional scenario. A planning discussion proposed reducing ticket reassignments. The trial log shows a two-week pilot at one support site, covering billing tickets during the day shift. The operational report records fewer reassignments than the preceding two-week period, but it does not establish that the ticket mix was comparable. The review discussion reports waits when the billing specialist was unavailable. A decision note records that the pilot ended as scheduled and broader rollout was deferred pending an answer to the coverage question.
Those inputs support this brief:
Approach
Route billing tickets directly to a specialist.
Execution and scope
Two-week pilot at one site, covering day-shift billing tickets.
Execution is established by the trial log.
Observed results
The report records fewer reassignments than in the preceding two weeks.
Comparable ticket mix is not established, so the size of the improvement
cannot be confidently attributed to routing alone.
Reported constraint
The review discussion describes waits when the specialist was unavailable.
The available records do not quantify the effect on total resolution time.
Why the attempt ended
The pilot ended as scheduled. Broader rollout was deferred while the team
considered coverage; the record does not establish blanket rejection.
Current proposal
Add a fallback queue when a specialist is unavailable. This is a new
proposal, not a capability shown to have worked in the earlier pilot.
Question before another attempt
How would fallback routing and specialist availability be tested, and
what outcome would the team use to judge the new approach?The earlier attempt gives the new proposal a concrete problem to address. It supports neither “routing never works” nor “we proved routing works.” Its limits are part of the learning.
Use a reusable past-experiment brief
Idea or approach:
Original question:
Was it proposed, approved, or actually tried?
Where, when, and with whom was it tried?
What was observed, and where is that recorded?
What limits the interpretation?
Why did it stop or change?
What is different about the current proposal?
What still needs confirmation?
Sources:For a brief spanning several records, ask an AI agent connected to Hemory:
Prepare a brief on the earlier specialist-routing experiment.
Use the available Hemory planning and review discussions, plus the trial
log and results I provide.
Distinguish a proposal from execution. Preserve the trial's scope,
observations, limitations, and stated reason for stopping or changing it.
Separate recorded results from participants' interpretations.
Compare those findings with the new fallback-queue proposal I provide.
Do not infer failure or abandonment from missing follow-up records.
Include sources and identify the specific questions that remain open.Provide current documents and result files separately when the agent cannot access them. A Hemory connection supplies available conversation context, not automatic access to every experiment record.
Decide what the next attempt needs to learn
Use the recovered brief to avoid repeating a test unchanged or dismissing a genuinely different proposal. The next step may be to retrieve a missing result, clarify the original conditions, or propose a new trial with an explicit learning question.
For the routing example, a new trial could examine whether fallback coverage addresses the earlier waiting problem. The team still needs to agree the design and how to assess it; the historical record does not supply new acceptance criteria automatically.
If the task is to reconsider an established project decision, use the decision review guide. This brief supplies past learning that can inform that decision.
Share the necessary explanation in the team’s working space, including the limits of the evidence. A short entry with clear scope is more useful than “tried before—failed,” especially for someone who did not participate.
FAQ
What if nobody can find results?
State what the records establish about execution and what remains unknown. Ask participants for specific observations and label later recollections as such. Missing results do not prove that the experiment failed.
Can an earlier result apply to another team?
It may inform the proposal, but compare the population, process, staffing, and other relevant conditions. A local trial is not automatically evidence for a broader rollout.
Should every old idea have an experiment brief?
No. Prepare one when the previous attempt could change a current proposal. For a broader review of lessons from a completed stage, use the project retrospective guide.
The next time someone says, “We tried that already,” use Hemory to recover the captured discussion and pair it with the trial evidence. Give the team the learning it can use, not just the remembered verdict.
