LOL. Yes. Or build something like this, a solution that almost everyone, especially in the no-code realm, wants to avoid. Enterprises are more inclined to do this, but even so, it’s a very narrow audience who will go to this trouble to incrementally improve that which the Airtable client automation is completely inept at achieving.
Users want optimistic saves and no-ode solutions in the worst way, and they got them. Now, they want features that cannot be provided, given those constraints. The irony of all this code for a no-code platform continues to expand. 
To tidy this up, I’ve had a difficult time getting Airtable community users to engage here in Table Forums, so I’ll finish this topic by addressing the inquirer’s follow-up comments here.
The expectation is not unreasonable. You can specify which table or even field update should send a notification. It is not unimaginable that you would be able to specify what specific interaction(input in progress, completed input) would send a notification as well. But as far as I understand that is not currently possible.
Whether it’s reasonable or not is a great debate, but not without recognizing technical challenges. The big one is optimistic saves. Is it reasonable to enforce a button to save every record change? If not, it’s unreasonable to expect this requirement is a reasonable expectation.
Information that would let to identify what interaction happened with the field is also not present in the payloads.
As a collection, the payload list does provide the data necessary to determine with high probability what occurred in the client app. I think the inquirer is not looking at the events notifications as a signal to fetch the latest stream of user consciousness. Supporting my hunch, this passage seems to suggest this is the case.
A workaround would be to check the payloads every x time …
This is not a workaround, it is the documented approach except for one thing - the polling part. You don’t need to poll every so many seconds or at any interval for that matter. This entirely defeats the benefit of an event-driven API. You use event broadcast signals to request the latest and most complete stream of events which are provided as a collection for a given event type/users/field. It is your job to interpret this stream of activity however your use case demands.
… but again that defeats the purpose of using webhooks.
This user has assumed that all webhook systems are designed the same. Many, not all, webhook architectures send a hook notification that includes the field data before and after the change, and such hooks are broadcast when - and only when - the platform has deemed a change has completed.
This more “helpful” design choice has some drawbacks, such as removing the ability to decide for yourself when hooks should be acted upon and under what circumstances. A “helpful” design is useful to many low-code developers because it is less work, less complexity, etc. Airtable has not provided this “helper” attitude to its Enterprise Events API, and I can understand why - they chose an agile webhook architecture that disfavors the low-code developer but probably favors the enterprise developer.