An experiment is not finished until it is written down
An experiment that is not written down is a story. A short, honest write-up turns it into evidence that other people can use, check and build on.
What a write-up contains
- The question. What we set out to find out.
- What we built. A short description of the prototype or trial, and the environment it ran in.
- What we found. Results in plain words, including the misses.
- Limits. What the experiment did not test and why the result may not carry over.
- Next steps. Stop, change direction or turn it into a project, with the reasoning.
Typical ServiceNow write-ups
Most of our write-ups are about ServiceNow. Topics include a comparison of two catalog designs, the results of a CMDB data-quality check on a sample, what an integration did under messy input, the effect of an upgrade on a set of customizations and the time saved by automating a routine administration task. Each is written for a reader who knows ServiceNow but was not in the room.
A ServiceNow write-up, step by step
To show what we mean, here is the shape of a typical ServiceNow write-up. It opens with the question, for example whether a redesigned ServiceNow catalog item is completed correctly more often than the old one. It describes the ServiceNow instance used and the copy of data it held. It lists what was tested, such as the form, the approval route and the notifications. It reports what happened in plain words, including any ServiceNow behaviour that surprised us. It closes with limits, such as the test using only a small group of users, and a recommendation on whether to build the ServiceNow change properly.
Typical AI write-ups
Our AI write-ups describe what a tool did on a set of real examples, where it was wrong and what a reviewer needed to correct. They also record data-readiness findings. We avoid summary claims such as “the tool works well” in favour of specific statements about what it did on which cases.
Typical Salesforce write-ups
We occasionally publish short write-ups about CRM workflow and integration experiments, following the same format.
Writing style
We write for busy readers. Short paragraphs, plain words, and no claims we cannot support. Where we are unsure, we say so.
Sharing
Write-ups shared with a customer are theirs to keep and use. We are happy to walk through them and answer questions.