Anyone with no ticket system, and no wish to introduce one, usually writes change requests as a perfectly ordinary email. That email becomes the working basis here, nothing extra to learn or sign up for.
The email gets read and analysed, which turns into a documented work item that gets implemented. The result does not go live directly, it lands on its own preview address with its own test data. Only once the customer has checked and approved that preview does the change go live.
This is how the whole change process already runs in the office of a building-services company: a batch of requests arrived as a single email, got implemented, was shipped to its own preview with test data, reviewed and approved. The customer adopted this way of working and praised it in writing.
What ports as-is
- The fixed order: trace every reported symptom to its cause first, discuss the open questions, then implement, test, ship to preview and only then check it end to end there, never the other way round
- A list of requests in the email is read as a description of what is not working, not as a finished work breakdown
- Fixed rules for the mailbox and data protection when testing against real customer data
- A fixed shape for the reply the customer receives
- The connection that reads the request straight out of the customer's own mailbox
- An assistant that checks the existing code first before the work item gets written
- The dedicated preview environment as the last step before approval
What we build for you
- The connection to your mailbox gets set up
- The preview environment with its own addresses and test data gets stood up
- It gets agreed what may go live without a second review
- Whoever writes the emails describes what is not working instead of proposing a finished solution
