Before automating an enquiry, write its review record
I'm Sarvesh, co-founder of ASCī Consulting. Anish and I work on AI, design, development and data. For our first public studio note, here's a small workflow pattern you can copy.
Start with a fictional enquiry: 'We need office cleaning twice a week, after 6pm.'
That sounds actionable, but access is still unclear. Instead of letting the request disappear into an automation, keep the request and its next decision together:
request_id: DEMO-001
original_request: twice-weekly office clean after 6pm
review_state: missing access details
reviewer: owner
next_action: confirm who opens the building
Three cases to write down before connecting real tools:
1. A duplicate arrives. Keep a stable request ID and link the repeated submission to the original, so someone can decide whether it is a repeat or a genuine change.
2. A required detail is missing. Keep it in review with one clear question and a named reviewer. Preserve the original wording while you clarify it.
3. A destination fails. Keep the attempt and its failure visible. Check what was actually saved before retrying, and leave enough context for the next person to continue.
The useful question is: what would a person need to know to resolve this exception without reconstructing the whole conversation?
We made a free working example with fixed cases for duplicates, missing information, conflicting instructions and a destination failure:
https://asci-consulting.pages.dev/workflow-automation/#working-example
Choose a case, run it, then try the recovery. It uses fictional data in your browser and has no live customer integrations.
For a paid implementation, we first confirm the actual process and remaining gap, then agree the scope, price and acceptance checks.
If these practical examples are useful, our optional studio emails arrive about once a month:
https://buttondown.com/asci-consulting
Confirm by email and unsubscribe from any update. This note and the demo stay open without subscribing.