PRODUCTS & SYSTEMS · 2026 · RELEASED · SALES 0
As the number of manuscripts grew, I began spending more time checking their state than writing them. I kept reopening folders to find the latest file, the response to a revision request, or the evidence needed at submission. I turned that working method into two products: Manuscript Control Desk for an individual researcher and Manuscript Agency Operations OS for editorial and support teams.
Both reached public sales pages with real workbooks, instructions and licence options. Sales checked on 3 September 2026 were zero. The gap between release and purchase was not another missing feature; it was traffic and trust.
Two SKUs
individual and team use
Public sales pages
both observed live
Checkout and delivery
not purchase-tested
Verified sales: 0
as of 3 September 2026
The decisions became harder to track than the files
Even one submission can involve a manuscript, figures, supplementary material, a cover letter, declarations and portal metadata. A revision adds new file versions and a record of how each request was handled. Once several manuscripts overlapped, careful folder names were no longer enough. I wanted one view that showed what needed attention, what was blocked and what evidence had to survive the submission.
Manuscript Control Desk began as a linked spreadsheet for an individual researcher. Separate sheets held manuscript status, next actions, submission materials and records. I added a quick-start guide, licence and support notes, product images and a seller kit based on the actual workbook.
The first release failed its language check
The product was intended for an English-language sales page, but an older bilingual package was selected for the first listing. Korean text remained in the files and publication was blocked. I rebuilt an English-only package, added an identity check for the release files and submitted it again.
This was a different kind of QA from checking spreadsheet formulas. For a downloadable product, the archive received by the buyer, the claims on the sales page and the language visible in the workbook must all refer to the same release. Passing internal file tests did not matter if the delivery package was wrong.
The second product changed the buyer
I kept the individual product and built a separate version for freelance editors, small agencies and larger support teams. Manuscript Agency Operations OS combined a larger linked workbook with an operations playbook, four SOPs, an intake form and client-communication templates. Licences were separated by team size and client-reporting rights.
The working path ran from a dashboard to approval, revision, submission evidence and client reporting. A person tracking their own paper and a team handling work for several clients do not need the same table. The two products are therefore recorded as two SKUs in one product lineage, not as two independent achievements.
Nothing moved after release
On 3 September 2026, both sales pages were live. They showed the product scope, screens from the workbooks and licence choices, and each had a purchase link. I did not buy my own products, so I did not verify the complete checkout and download-delivery path. There had been no sales notification, and verified sales remained at zero.
A larger product and a higher-value buyer did not solve the absence of traffic. It was easy to read more files, more templates and more QA as movement towards the market. In reality, those were evidence of production. Evidence that a buyer valued the work had to arrive from outside, through a purchase or a specific customer conversation.
I verified the workbooks and the public pages. I did not verify that somebody had a reason to pay for them.
What remains useful
The work clarified the recurring stages and evidence requirements in manuscript operations. It also left me with a release rule: inspect the language and identity of the exact delivery package, not just the source workbook. Those are useful internal results, but they are not sales results.
If I ran the test again, I would postpone another feature build. I would first ask a small number of working researchers or editors to show me the tables they already use, then remove one repeated manual task and see whether that mattered. The verified status of these products remains simple: released, with zero sales.
Project record
Period: 2026
Role: problem definition; structure, workbook, operating-document and licence design for two SKUs; language QA; and sales-page release
Internal artifacts: linked workbooks, quick-start guide, operations playbook, SOPs, intake form and seller materials
Externally observed: two public sales pages showing product scope and licence options
Not established: end-to-end checkout and download delivery, actual use, customer value, purchases or revenue
Status checked: 3 September 2026