An English Contact Form Is Not Yet an End-to-End International Enquiry Journey: What Netsujo's Code Shows

An overseas technical buyer reads an English service page and sends an enquiry. Was it stored? Will someone see it? Can the buyer expect a response in English? A translated page cannot answer those questions by itself.

Netsujo has a public English services page and an English contact page. On October 16, 2026, we reviewed the relevant public entry points and implementation source. This was a source-and-route review, not a completed production enquiry test. We have not used this review to establish delivery of acknowledgement emails, a human reply, or an overseas sale.

Evidence access: The English web pages are public, but the implementation inspected here is in Netsujo's private repository. The following findings are a bounded internal source review, not a publicly reproducible source audit.

Why the question goes beyond translation

A potential client considering an AI-agent evaluation or a proof of concept needs to determine whether the service fits, where to ask, and what follows a submission. An ambiguous result can prompt a duplicate enquiry. Missing or untranslated follow-up could interrupt a commercial conversation. These are concrete risks to test; they are not measured incidents or lost deals at Netsujo.

One option was to check page copy and layout only. That leaves server persistence and follow-up unexamined. Another was to infer success from production enquiry statistics; without the individual journey and its evidence, that would also be insufficient. We therefore separated what source code establishes from what an end-to-end run must still establish.

The branches visible in the implementation

The English contact form source (private internal source) provides English enquiry categories and POSTs to /api/contact with intakeLocale: 'en'. After an HTTP success it renders Enquiry received, along with a normal first-reply expectation of three business days.

Its 20-second timeout handling is more revealing. A timeout or network error is classified as an unknown submission outcome, not automatically as a failed intake. The interface warns against an immediate duplicate and supplies a submission ID for checking by another channel. That distinction matters because an interrupted client connection does not, on its own, tell the sender whether the server received the request.

In the contact API source (private internal source), a general business lead is persisted before a success response; a failed persistence operation returns HTTP 503. The English intake also skips the legacy Japanese Apps Script auto-reply path. That prevents an inappropriate Japanese auto-reply from this route. It does not, by itself, prove that an English acknowledgement is delivered elsewhere or that a human follow-up occurs.

These are findings about implemented source behaviour, not a claim of verified production mail delivery, conversion, or revenue.

The acceptance run we would perform next

This is a proposed test case, not a test result. An overseas company asks in English about evaluating authority boundaries in an AI-agent proof of concept. Using a company-controlled test address and no real customer data, a tester would:

1. Navigate from English services to the general enquiry form, without accidentally entering the partner/media or SIGNAL-specific routes.
2. Enter the English request and capture validation, browser state, submission ID and timestamps.
3. Confirm the stored lead in the authorized internal queue without copying personal information into editorial evidence.
4. Observe whether any acknowledgement arrives, in which language, and who owns a missing acknowledgement.
5. Have the responsible team member reply in English and capture the response timestamp.

The browser's success screen would not alone close the acceptance. Evidence would need to connect the test request, durable receipt and human response. A timeout would be investigated as unknown, not blindly retried.

The live English contact page explicitly identifies the partner/media form and SIGNAL intake and support links as Japanese-language routes. That is a concrete, currently visible language boundary for visitors. Even passing the general English enquiry route would not verify the partner/media intake or the SIGNAL diagnosis, report, payment and support journeys. The English SIGNAL integration contract (private internal source) explicitly leaves downstream child-service behaviour with its owning service.

The decision that follows

If a prospect cannot identify the right service, improve the explanation and routing. If the submission outcome is unknown, prevent duplicates and investigate the receipt. If a lead is stored but no appropriate follow-up occurs, resolve the acknowledgement and ownership process rather than rewriting page copy again. This is a suggested decision sequence, not a ranking of observed production failures.

The current conclusion is narrow: Netsujo has English entry pages and relevant intake code, while a documented end-to-end enquiry and reply still requires separate verification. For international B2B readiness, the acceptance unit should be one complete enquiry, not the number of pages translated.

For an AI, Web3 or PoC enquiry, see the English contact page. This article does not certify the full English response journey as production-verified.