Customer enquiries / Fictional study
A helpful reply, with the right limits.
A fictional shop gets a question about delivery and installation. See how a small set of business rules changes the reply.
The answer depends on what the shop knows.
A customer wants shelves delivered and installed by Friday. A useful draft needs the destination, available slot and confirmed installation price—not just a friendly tone.
- Ask for the delivery location when it is missing.
- Confirm availability before offering a slot.
- Only quote a price that has been checked.
“Could you deliver and install the shelves by Friday?”
Fictional customer enquiry
A quick reply can create a slow problem.
A draft that promises Friday without checking the schedule sounds helpful, but creates a commitment the shop may not be able to keep. The review needs to check the facts as well as the wording.
- Read the customer’s request.
- Look up the destination and schedule.
- Check the installation price.
- Prepare a reply that reflects what is actually known.
Change a fact. See the reply change.
Select what the shop has confirmed. The sample draft updates below, ready for a person to review.
Open the full email demonstration ↗Draft for review
Thanks for getting in touch. What is the delivery postcode? I’ll check availability before offering a delivery slot. I’ll confirm the installation cost before you decide.
A person still reviews this draft before sending.
Preset simulation. No inbox connection, live AI call, email sending or saved visitor data.
A small, inspectable workflow.
This browser example demonstrates a proposed set of rules with authored replies. It lets a prospective client understand the behaviour before connecting an account or commissioning a setup.
Business context
Destination, schedule, price and a rule against making unconfirmed promises.
Browser rule logic
The selections assemble preset wording. This portfolio demo does not use a model.
Human approval
A person checks the facts and decides whether to send.
A possible next experiment
Compare model-generated drafts on the same test cases, then test a Gmail or Outlook draft connection in a sandbox.
A connected morning-inbox assistant would be a separately scoped implementation, with its own tests and permissions.
Could something like this help with your work?
Tell me about your process. We can work out what would be useful for your business.