Writing Clear Calls to Action for Architecture and Property Websites

“Request a quote” asks too much of a client who has yet to establish a site, scope or budget. “Send us your site address and a brief project outline” gives them a manageable next step and tells them what the practice needs. A useful call to action (CTA) fits the question a visitor has reached, rather than pushing everyone toward the same form.

On an architecture or property website, that step might be an inquiry. It might instead be a list of documents needed for an initial review or contact details for an occupied building. The visitor should be able to choose without guessing what happens after a click.

Match the action to the decision at hand

A homeowner reading about compact housing may still be weighing an extension against a new layout. A developer on a service page may already have a site and a programme. A facilities manager looking for operational guidance may need information, not a design consultation. A single “Get started” button obscures those differences.

First, identify the decision the page helps someone make. Then offer a next step that asks for a similar level of commitment:

  • Early exploration: “Review the information needed for a feasibility discussion” helps visitors prepare without committing to a project.
  • Defined project: “Submit your site and project brief for an initial review” suits someone who can describe the location, intended use and broad scope.
  • Specific technical question: “Send the existing drawings and describe the proposed change” works better than a general inquiry when those materials are needed to assess the question.
  • Operational request: “Report a building access issue to the facilities team” should lead to the appropriate channel, not an architectural sales form.

The destination has to match the wording. If a button says “Book a consultation,” the next screen should offer a booking process or explain how a time is arranged. An unlabelled general form leaves the visitor to work that out.

Client and architect discussing plans at a table

Say what the visitor will provide—and receive

“Send a project outline” says more than “Submit.” Supporting copy can explain the exchange: “Include the site address, intended building use and any existing drawings. We’ll confirm whether an initial discussion is appropriate.” That sets an expectation without promising a design answer before anyone has reviewed the material.

If the practice can reliably give a response time, clarify whether it means business days. Say, too, whether the visitor should expect an acknowledgement, a request for more details or a substantive review. Do not promise a deadline the team cannot consistently meet. If an initial conversation is free but a feasibility study carries a fee, make that distinction before the visitor sends sensitive project information.

Keep the first request proportionate

An initial inquiry rarely needs every document required for a full commission. Ask first for what helps the team route and assess it: contact details, location, building type, intended work and an approximate timeframe. Keep optional fields genuinely optional. Detailed surveys, title documents or financial information can be requested later, if relevant, through an appropriate process.

A little form guidance can prevent confusion. State whether uploads are accepted, which formats work and any file-size limit. If the form is only for new projects, give existing-project and building-management questions a separate route. The destination should let people complete the task the CTA describes.

Put the invitation beside the information that earns it

Give visitors enough context before asking them to act. A service page may need to explain its scope, exclusions and typical project stages before inviting a discussion about a commission. A permits page should distinguish the architect’s design work from the authority’s approval decision before asking for drawings. Place the CTA after the relevant explanation, not in the middle of it.

One primary action per section is generally easier to understand than several equally prominent buttons. Keep secondary options available as plain text—for example, a link to project requirements for someone not ready to get in touch. Repeating the same button after every short paragraph adds little; use it where the reader has enough information to act.

Check the mobile layout, too. A CTA beside its explanation on a wide screen may end up far from it when columns stack. Read the button label in its mobile position and check that the nearby text still describes the same action.

Project inquiry fields displayed on a phone

Write for accuracy, not pressure

Urgency needs a real basis. “Contact us before submitting planning documents” may help when early coordination matters to the service described. “Limited slots—act now” misleads if no such limit exists. “Get your permit approved” is particularly risky: an architect can prepare and coordinate an application, but the relevant authority decides whether to approve it.

Specific wording also helps with accessibility. “View the drawings required for an initial review” makes the destination clearer than “Learn more.” Use descriptive link text, visible focus states and buttons that work with a keyboard. Keep essential instructions outside disappearing form-field hints so visitors can understand the task before they enter information.

Check whether the CTA works in practice

Submission counts do not tell the whole story. A prominent button can attract clicks yet produce incomplete forms or inquiries intended for another team. Look at the full path: can people find the CTA, reach the intended page, complete the task and receive an appropriate response? Where possible, compare the quality of inquiries with the pages that generated them.

When traffic allows, test one change at a time and record what changed. If inquiries are sparse, a short usability review may tell you more than a percentage comparison based on a handful of submissions. Ask someone unfamiliar with the site what they expect after selecting the CTA, then check that against the process they encounter.

Finally, send a test project inquiry from a phone. Check that the button label matches the form, required fields are clear, the confirmation message says what happens next and the request reaches the person responsible for replying.

Scroll to Top