Search teams make changes, wait, look at results and try to work out what happened. Their notes do not always survive that sequence. A product on SEOT.com could give consultants a dependable record of the question, the change and the observation. Its purpose would be to help a team reason more carefully about its own work, especially when several people touch the same website.
This is a possible product direction. I would begin with an experiment journal that is useful before it becomes analytical software. A consultant should be able to open a record weeks later and explain what the team expected, what it actually changed and what else happened during the observation period. That is a specific job with a useful finished result: a record another person can read without reconstructing the project from messages.
Start with a question that can be answered
A vague goal such as improving search performance is hard to investigate. A better starting record names a page group, a proposed change and an observation the team plans to compare. For example, a team might want to understand what happens after it rewrites a confusing set of page titles. The record can identify the pages and the reason for the change before anyone edits the template.
The application could prompt for a short hypothesis in ordinary language. It should also ask what decision the team expects to make afterward. Will the team keep the revision, investigate a different approach or run a narrower follow-up? That question prevents the journal from filling with interesting charts that never lead to a practical decision.
Preserve the starting conditions
A useful record captures what the team knew when it began. Include the page group, relevant dates, a sample of the original content and any other work already scheduled. Keep attachments close to their explanations. A screenshot without a date or a filter description can become difficult to interpret after a few releases.
I would make the baseline easy to review and difficult to overwrite accidentally. If someone later discovers that the original group included an unrelated set of pages, add a correction with its own date. Preserve the original record so the team can see how its understanding changed. That is more informative than silently replacing the starting point.
Record what actually shipped
Plans and releases often diverge. A developer may change the page set, postpone part of a template update or include another fix in the same deployment. The journal should have a separate change record for what actually shipped. A link to a release or ticket can support it, but a plain description should still explain the work.
A timeline could distinguish the proposed date, the actual release and the beginning of the observation window. That helps a consultant avoid comparing a period that includes days before the change existed. The product should make these ordinary details easy to notice rather than hide them behind an impressive summary score.
Keep observations separate from explanations
The strongest design choice may be two separate fields: what the team observed, and how it currently interprets that observation. The first is a description of the selected evidence. The second is a working explanation that may change. Giving them separate places lets a colleague challenge an interpretation without losing the underlying record.
Other events belong nearby. A campaign, a site outage, a content release or a change in the selected data can complicate a comparison. The product does not need to declare every experiment invalid when that happens. It needs a clear way to record the event and explain how it affects the confidence of the team's conclusion.
Make review a short conversation
A consultant reviewing an experiment wants to know whether it has enough evidence for the next decision. A small review screen could show the question, the shipped change, the observation window and the unresolved concerns. The reviewer can ask for another period of observation or approve a follow-up without writing a separate report from scratch.
The first version could work with manually attached evidence. That keeps the founder focused on the quality of the record rather than a broad integration roadmap. A few teams using the same template will reveal which fields help and which ones are routinely skipped. Those are concrete signals for the next product revision.
Build an archive people can learn from
After several months, the archive should answer more than whether an experiment was completed. A new team member could look up earlier work on a template, read why a change was kept and avoid repeating a question that has already been investigated. Searchable tags can help, but the plain-language conclusion remains the most useful part.
SEOT gives that repeated work one compact identity. A founder can put it on an experiment link, a review invitation and the archive itself. The name leaves room for a serious product without requiring every feature to arrive at launch. Its character can come from helping teams preserve careful decisions.
To test this direction, gather three completed projects and reconstruct them using the proposed journal. Note every missing date, unclear page group and unsupported conclusion. Then try the same record on one new change. That comparison gives a founder a grounded way to decide what the first version should do. Ask about SEOT.com if this is the product you want to give a permanent home.