A working change-request process for an organisation that has no ticket system and does not want one: the customer’s plain email is the specification, it is pulled and analysed with work-intelligence tooling inside the working session, turned into a documented work item, implemented, and deployed to an isolated preview environment with its own test data and addresses. The customer reviews a working URL and approves, and only then is it promoted.
What ports as-is
- The method and its tooling: the fixed order (analyse every reported symptom to its cause, discuss the genuine ambiguities, implement contract-first across surfaces, unit test what changed, deploy to preview, then run end-to-end against the deployed slot and never the reverse)
- The rule that a numbered list is symptoms and not a work breakdown
- Mailbox and data-protection rules for testing against live customer data
- The customer-facing reply shape
- The mail-intelligence connector that reads the request out of the tenant
- The grounded issue-creation skill that scans the code before writing the work item
- The isolated preview slot as the acceptance gate
What we build for you
- Connect mail intelligence to their tenant and name the intake mailbox
- Stand up the preview slot with its own addresses and test data
- Agree what may be promoted without a second review
- Train whoever writes the mails to send symptoms rather than proposed solutions
