Incoming leads need a next step

Start with an existing flow

I used the DS contact form to test that path. The site already validates an inquiry, sends a notification and prepares an acknowledgment. I added a downstream record to the trial with an owner, a state and a next action.

The trial ran locally with six synthetic inquiries. They went through the form and its sending logic; the email provider, people's replies and the passage of time were simulated. That let me examine the flow without attributing commercial activity we have not observed.

Keep the inquiry moving

In the trial, I was the owner. A new inquiry waited for a response from the business. When the business replied, the state changed to waiting for the contact and the next action became follow-up. Another reply from the contact put work back on our side.

Preparing a task did not mark the inquiry as handled. That change required a later event. I also tested closure: a closed inquiry stopped appearing among the pending items.

These distinctions matter when deciding what to work on. An email waiting for our response and another waiting for the customer may sit together in the inbox while requiring different actions.

Six inquiries, eight form submissions

One case simulated a lost response after the provider had accepted the notification. The form indicated that the send had not completed. Repeating it with the same identifier kept a single inquiry and its original due time. Another repetition preserved that result.

In another case, I prepared a follow-up task and then introduced a reply from the contact. The earlier task was superseded and the next action became reply. Processing that same response again did not postpone the due time or add another task.

Five trial inquiries were recorded. One was closed. Reopening the store and advancing the test clock selected four pending tasks. A second planner pass kept those same four.

Where the record received nothing

The sixth inquiry exposed a limit of where I had placed the record. When the simulated provider rejected the notification before accepting it, the form indicated unavailability. The downstream record never received that inquiry, so it could not assign a next action.

Covering that failure would require saving the inquiry as it enters the application. Notification would become a later step with its own retry. The trial made that integration decision and the remaining work visible.

That is useful when designing the flow: automation that starts by reading notifications depends on those notifications coming into existence.

What to develop after this trial

This first trial focused on keeping the state and next action. Real email receiving and AI response generation remain for another test.

AI can help recover context, summarize an inquiry and propose a response. The record should make it possible to review where that proposal came from and what happened afterward. With that flow operating, we can measure inquiries handled, response times and next steps completed.