The best way to contact the site and what to include
The primary email address for this site is contact@aigotowork.work. The backup contact address is midoriko053@gmail.com. If the primary address bounces, if you do not receive a reply in a reasonable period, or if your mail system blocks one address, use the backup. Listing both addresses openly is deliberate. The site is intended to be transparent about how it can be reached.
If you are writing about a site issue, include the exact page URL, the device or browser you used, and what you expected to happen. For example, “the Budget summary did not update on vinyl-fence.html after switching from pro install to DIY in Safari on iPhone” is far more actionable than “the calculator is broken.” Clear reproduction details make bugs easier to verify and fix quickly.
If you are writing about content accuracy, include the sentence or section you think is wrong, what you believe the correction should be, and why. If you have a code citation, a manufacturer specification, or another concrete source that explains the issue, include that too. Corrections are easier to review when they are scoped tightly to a page, a paragraph, a data assumption, or a user-flow problem.
Reasons to contact the site
Support and correction requests are the most important category. That includes broken page behavior, confusing copy, accessibility issues, incorrect assumptions, or a page that creates a misleading impression. If the site says something that is unclear or not specific enough to be useful, that is worth reporting. Practical feedback is one of the fastest ways to improve a planning tool like this.
Business and partnership requests are also fine, but they should be explicit. If you want to discuss licensing, syndication, a content collaboration, a tool recommendation, or another business matter, say that in the subject line. The more precisely you define the request, the easier it is to decide whether it is a fit. Generic outreach that only says “let's collaborate” without context is much harder to evaluate and tends to slow everything down.
Press and editorial requests should identify the publication, deadline, and what you need. If you need a quote on how homeowners should think about fence estimating, say so directly. If you want permission to reference or quote a page, include the page URL and where the reference will appear. Clarity is especially important for editorial use because a planning site like this is most useful when it is represented accurately.
No public support form and no fake inbox
This site intentionally does not use a public web form. That is partly a product choice and partly a trust choice. Many small sites publish a contact page with a form that is never monitored, badly spam-filtered, or routed through a third-party script that provides a poor user experience. A direct email path is more honest. If you write in, the message goes to the listed address rather than into a silent or opaque pipeline.
The site also does not offer phone support, live chat, or guaranteed turnaround windows. That is not because the contact page is decorative. It is because the site is a planning tool, not a staffed help desk. The right expectation is that thoughtful messages with clear context are easier to answer well than a high volume of unstructured requests.
What to include if your message is time-sensitive
If your request is time-sensitive, put that in the subject line and explain why. For example, a press deadline, a broken calculator behavior affecting many users, or a major content error is a stronger reason to mark urgency than a general question that is already addressed on the FAQ or cost guide page. Urgency is easier to understand when it is tied to a concrete impact.
If you are a contractor or supplier writing with product feedback, it helps to separate opinion from specification. “Our crews prefer X layout” and “this manufacturer only allows Y rackable range” are not the same kind of input. Both can be useful, but they should be labeled clearly. The site is more likely to incorporate feedback when the suggestion is practical, specific, and framed around how it improves planning accuracy for users.
Accessibility, corrections, and abuse reporting
Accessibility issues should be reported directly, especially if you ran into a keyboard trap, missing label, poor contrast issue, or a page structure problem that made the calculator difficult to use with assistive technology. Those issues matter because a planning tool is only useful when people can actually operate it. Include your browser, device, and the accessibility problem you encountered.
If you see abuse, impersonation, or a page cached somewhere with stale content that could mislead users, report that too. The site cannot control every mirror, archive, or screenshot, but it can review reports and correct the live version where needed. If the issue involves an indexed page, include the full URL and a short explanation of what the problem is. That makes the report much easier to act on.
How incoming email is handled
Incoming mail is used to read and respond to site-related requests, review correction suggestions, handle technical issues, and manage legitimate business communication. It is not meant to create an account relationship and it is not tied to a lead-generation promise. If your message is only a project question that is already answered on the site, you may be directed back to the relevant calculator or guide page rather than receiving custom project consulting.
Do not send sensitive information that is unnecessary for a website support request. You generally do not need to send full addresses, payment details, identification numbers, or private contractual documents just to report a calculator issue or ask a question about the content. Keep support messages proportional to the request. That is better for your privacy and better for site handling.
What makes a correction request genuinely useful
The most valuable emails are usually narrow, testable, and specific about impact. If you think a page is incomplete, explain what a careful user would still be unable to decide after reading it. If you think a calculator assumption is weak, explain which material type, installation condition, or region makes the assumption unreliable. If you think a page headline overpromises, quote the line and explain how a more accurate version should read. This kind of message is far easier to evaluate than a general statement that the site should be “more accurate.”
It also helps to say whether the issue is factual, structural, editorial, or technical. A factual issue means the content is wrong or outdated. A structural issue means the page flow makes it hard to compare options or understand the workflow. An editorial issue means the wording is vague, overstated, or missing an important limitation. A technical issue means the page or calculator behavior failed. Those distinctions matter because they point to different fixes, and the right fix is not always a code change.
When the site may not be able to help directly
Fence Calculator can help explain how the site works, what assumptions are behind a result, and whether a bug or content issue should be reviewed. It cannot function as a replacement for a local contractor, permit desk, utility locating service, land surveyor, structural engineer, or product manufacturer. If your question depends on an exact property line, utility conflict, code interpretation, or a brand-specific installation requirement, email may still be useful for pointing out where the page could be clearer, but it may not produce a project-specific answer.
The site also cannot mediate quote disputes between homeowners and contractors or approve a build plan for a real property. If two installers disagree on scope, post size, or gate framing, the right next step is usually to compare written scopes, manufacturer documents, and site conditions rather than expect a static calculator page to settle the issue. This contact page is therefore best used for site support and editorial clarity, not as a substitute for field judgment on a live project.
Editorial, media, and partnership requests
If you are writing on behalf of a publication, newsletter, software company, supplier, or industry organization, include your role and the exact purpose of the request. A request to quote a page in an article is different from a request to syndicate content, review a calculator partnership, or discuss data licensing. Putting the intended use in the first message saves time and prevents confusion about whether the request is editorial, commercial, or technical.
If the request involves referencing Fence Calculator publicly, include the target URL, publication or platform name, expected audience, and timeline. If the request involves correcting a public statement about the site, include the published claim and why it is inaccurate. That level of specificity supports a cleaner review process and reduces the chance that a useful request gets delayed because the objective was not clear.