The form worked.
The wait did not.
Two recorded enquiries took 11 and 19 minutes to reach our inbox after acceptance. The connection was there. The delivery needed attention.
The work / design & engineering
The freedom
is in the details.
A visitor should know what to do. Your team should know what happens next. Start with the enquiry system on this site, then look at the software behind the work.
See how we beginIn use here / dgl’s own enquiry system
A good first impression
should reach someone.
A short form is only the beginning. The note needs to arrive, the person receiving it needs the context, and the reply needs to reach the visitor.
The form worked.
Follow the whole exchange.
We traced and repaired the delivery connection, kept the visitor’s words together and made confirmed, pending and interrupted submissions distinct.
Ready for a real reply.
A marked browser test reached our inbox in about six seconds. Reply addressed the visitor and kept the original paragraphs. No retyping or searching for the address.
Our own operating website. Recorded checks, not a client testimonial. The later test was on ; its timing is approximate, not an average or delivery promise.
A thank-you screen is only half the check.
Test what the person receiving the request can actually do next.
Use the enquiry checklist ↗What was checked, and what it establishes
From the page to the reply
A single marked test was submitted through the live form and located in the receiving mail app. The actual Reply control selected the submitted visitor address and preserved their paragraphs. That verification reply was not sent.
The browser keeps a pending note available for a status check. It does not automatically submit a new enquiry after an uncertain connection.
The limits matter
The later measurement was approximately 6.3 seconds from click to inbox. The earlier waits started at mail acceptance, so these are separate observations rather than a matched speed comparison.
This establishes the checked delivery and reply path. It does not measure sales, customer satisfaction or every future delivery.
Keep the implementation record JSONSelected work
Built here.
Useful in your world.
Three products from our own development. Each addresses a practical problem; a client project begins with the part that fits.
Our own product development
Service operations platform
One job record. A clear next action.
The team should not need you to reconstruct a job. Our service platform keeps the request, work record, estimate and next responsible person together.
“Just checking in” should not be a department.
Receive
Intake, work logs and estimate lines belong to the same job record, alongside the parts and tasks it needs.
Assign
Owner, manager, technician and front-desk actions have separate permissions. Responsibility stays with the work.
Notice
Rules identify unanswered estimates, overdue parts and quiet jobs. Reminder records distinguish created actions from duplicates that were skipped.
Roles, rules and connections are agreed for each business.
Inside the implementation
- One work record through the job
Queue and detail views connect intake, work logs, estimate lines, parts and assigned tasks.
- Specific permissions
Owner, manager, technician, front desk, buyer and viewer actions are defined separately.
- Actionable exception rules
Rules identify vague intake, missing work logs, unanswered estimates, ready-for-pickup work, overdue parts and quiet jobs.
- Reminders without duplicates
Rule results are deduplicated and audited, with created and skipped outcomes.
Our own product development
Private communications · Native and browser applications
The conversation, with its context.
Give the next person enough context to reply. Our native mail application and browser companion bring messages, drafts and attachments together with project material.
Read and draft
Mailbox views, message state, saved drafts, sending and attachments support the daily conversation.
Organise
Explicit controls handle bulk actions, while separate administration covers mailboxes, quotas, aliases and forwarding.
Keep context
Scoped project documents sit alongside communication. A smaller browser companion supports mail and a bounded service-desk handoff.
Connected to the mailboxes and permissions agreed for each setup.
Inside the implementation
- The complete daily message loop
Mailbox and message views connect reading, seen state, sending, saved drafts and attachment uploads.
- Mailbox administration
Dedicated actions cover mailbox creation, quota changes, aliases and forwarding.
- Project context beside communication
Workspace and scoped project-document models connect messages with project material.
- A smaller browser companion
The browser flow handles sign-in, mailbox navigation, composition and drafts, with a bounded handoff to the service desk.
Our own product development
Private build and delivery platform
Review the change. Keep the way back.
Approve a change knowing which version is ready for release and how to return to the earlier one. Our private build platform keeps the request, working preview and saved versions together.
Request
The workspace keeps the build request, access roles and progress together. Progress has a durable record, including completion and errors.
Review
A checkpoint records the exact files and their checksums. Its isolated preview lets someone review that saved version.
Restore
Restoration checks the saved files and the resulting copy. If the replacement fails, the earlier site remains recoverable.
Reviewing a preview does not publish it. Acceptance and release refer to an exact version and target.
Inside the implementation
- Build progress survives a page refresh
Queued work has a durable turn record and event stream, with explicit completion and error states.
- A real version to review
Each checkpoint declares its files and digests, verifies the copy, and freezes the saved version.
- Verified restoration
Restoration copies the declared files, verifies the resulting digest and replaces the current site with rollback for a failed swap.
- Preview without hidden external actions
The generated preview blocks network connections, forms and embedded frames while rendering the checkpoint.
- Separate acceptance from release
Release-readiness and request endpoints bind to an exact checkpoint and target rather than treating a preview as publication.
Keeping the knowledge with the work
Instructions someone
else can follow.
For this site’s source, a separate AI agent started with a clean copy and the project documentation. It rebuilt the site, made a local text change, then restored the original output exactly.
What the exercise foundThe build was reproducible. The instructions missed a runtime setup step needed to run the checks. We added it to the handover guide.
What it does not establishThis was a local source exercise on the 28 September release, not a human taking over a client system. Production accounts, mail operation and live deployment were outside the exercise.
Inspect the handover check
Rebuild. Change. Restore.
The clean build matched the saved release. The local edit appeared in the served page. After restoration, the complete static output matched again. Static checks passed at all three stages.
Keep the source check JSONApply it to your own handover
Ask the person taking over to follow the instructions in a safe copy. If they need an explanation that is not written down, the handover has something left to do.
Use the handover checklist ↗A closer technical look: a change you can undo
Inside our software / a recorded check
A change you can undo.
You should be able to review a change without losing the version you trust. We put our private build platform through that exact task.
Our own software · Isolated test data ·
- 01
Save, then change.
The platform saved the original page, processed a sample edit and kept both versions available to review.
- 02
Catch an outdated instruction.
An instruction based on the earlier state was rejected. It left the newer work and its history untouched.
- 03
Return with confidence.
With the current version identified, restoration succeeded. The restored file matched the original exactly. The later version remained available.
Text from the actual saved files
The earlier version
Private client requests.
Tell us what you need.
The changed version
One request. A clear next step.
Tell us what needs attention and who should receive the reply.
Restored file: exact match with the earlier version.
A small sample page used to check the software. This is a recorded run, not a client project or a live control panel.
Applied to your business
The parts connect.
A public presence, the work behind it and the control around it. We agree which part needs attention first and how it fits what you already use.
The first impression
Present your business.
Give the right visitor a clear understanding of the work and a considered way to enquire, book or decide. Connect the words, design and next step.
Identity & words · Websites · Client journeys
What happens next
Run the work.
Keep requests, conversations, responsibilities and approvals together. Build the missing connection around the way the team actually works.
Private workspaces · Service & booking systems · Native applications
What remains yours
Stay in control.
Agree who can change what, review releases and keep a recovery path. Leave the business with the source, access and operating knowledge agreed for the project.
Domains & hosting · Permissions · Version history & recovery
Explore the behaviourTry a few examples
Four interactive illustrations using fictional business data. They are separate from the recorded software check and product descriptions above.
Interactive examples · fictional business data
Choose an example below. Your changes stay in this page.
A decision, with the context intact
Know what
needs you.
See what changed, who owns the next step, and which decision is yours.
Your decision record
From a customer request to a responsible person
Let routine
work move.
An enquiry should arrive with enough context to move forward. The ordinary work goes to the team. An unusual request reaches the person who can decide.
- 01 Enquiry
- 02 Named owner
- 03 Clear next step
What the team will receive
A useful request.
A clear responsibility.
The handoff will include the requested service, timing, responsible person and any decision that needs review.
Explore the handoff here, then download a copy.
A real version to review. A way back.
Change with
confidence.
Compare the current page with a proposed change. Accept the new version, restore the earlier one, or keep a standalone copy.
Version 2 is ready for review. Version 1 remains accepted.
The change you are deciding on
A clearer invitation.
- Before
- Thoughtful spaces.
Get in touch. - Proposed
- Rooms for the way you live.
Tell us about your space.
The service becomes specific, the invitation explains what to do, and the visitor can see what information to share.
Version record · this page only
Know what you own. Know how to take it with you.
Keep the
business yours.
Know who controls the website, domain, mail and records for each business. Choose a system, update the responsible roles, and keep the handover inventory.
Keep all four systems, responsibilities, dependencies and exit steps together. Use these planning notes to check ownership with your team.
For your business, we agree the connections, access and responsibilities before putting a system to work.
- 01
Follow the real task.
Trace one recurring task or decision. See why it reaches you and what information is missing.
- 02
Agree the useful result.
Agree what the change will do, what it will cost, who owns it and how we will check it together.
- 03
Use it. Then hand it over.
Review the normal path and the exceptions. Leave with the agreed source, access, operating instructions and recovery.
Less on your mind.
More in your hands.
Start with one part of the business that asks too much of you.
Tell us about it