Can clients receive enquiries through a native QREasy contact form?

No. QREasy websites do not provide a native customer contact form or enquiry submission inbox. Use phone, email, WhatsApp, or a link to a separate provider already used by the business. Those routes start an external interaction; they do not automatically create a reservation, booking, order, or client record.

Can a Free website publish every section shown in a template?

No. Free supports the listed free section types, but premium section types require Lite SME or Business to publish. Premium content can be drafted before upgrading. Distinguish a template’s starting sections from blocks added later, and confirm that editorial layouts and image sliders require a paid plan.

Do I need a dynamic QR code every time website copy changes?

Usually not. A static URL QR can continue to open the same URL after the hosted page is edited. A dynamic QR is useful when its managed redirect destination must change without reprinting, within plan limits. If the encoded static URL itself changes, create a new static QR. No QR type guarantees scanning on every device.

Does a website-linked Wallet card open inside Wallet?

No. Website-linked Wallet cards require Lite SME or Business. Their QR encodes the website URL and opens it through the phone browser, rather than running the site inside Wallet. Google Wallet also includes a Visit Page link. Opening the website does not depend on a mandatory card-review step.

Website Checklist for Clients: A Practical QREasy Guide

Start freeStart

Website Checklist for Clients: A Practical QREasy Guide | QREasy

Define the scope, audience, and template

Begin with a one-sentence outcome, the intended audience, and the main action a visitor should take. Decide whether the deliverable is a one-page site, a multi-page small-business website, or a broader information site. If the choice is unclear, compare a microsite with a landing page before approving a page structure.

Then choose the closest template based on business type and content, not decoration alone. Record the required pages, section order, audience, approval owner, and deadline. The business-card and Event templates have different starting sections, so their defaults must be checked rather than assumed.

Outcome: what should a visitor do?
Audience: who is the site for?
Structure: which pages and sections?
Ownership: who supplies and approves content?

Collect content for every page

Create one content checklist per page. Request final wording, product or service descriptions, opening hours where relevant, contact details, photographs, and links to external resources. Confirm ownership and permission for every image or document, and identify changing details rather than treating them as permanent copy.

Label every item by destination: heading, body, image, link, contact action, booking route, or download. Ask for spare image variants and the exact destination behind each button. Mark unfinished items as placeholders and keep them out of final approval until replaced.

Final copy for every page
Images with permission to publish
Services, products, and past work
Current contact and social links
Names, hours, locations, and downloads

Map content to supported sections

Map every planned block to a supported section before visual approval. Free sections include Restaurant menu, Links, Products, Gallery, Text, Contact, Social, Save Contact, and Events. Ordinary Text can explain services or past work, and Gallery can display photographs; this does not make premium service, profile, or editorial blocks free.

Premium publishing options require Lite SME or Business. They include music, video, channels, downloads, CTA, image, premium gallery, service grid, FAQ, publications, credibility strip, locations, stats strip, before-after, profile, team grid, testimonials, process, and technology list; editorial layouts and image sliders also require a paid plan. A premium block can be drafted on Free, but not published there.

Distinguish defaults from additions. The business-card template starts with Save Contact, Contact, and Links, not a ready-made services area. The Event template starts with editable Text, Links, and Contact, not a registration or scheduling system.

Confirm free or premium status for every block
State whether each section is a default or added later
Upgrade before publishing any restricted section

Document enquiry and contact routes

Document how the client handles enquiries and state the expected result of each route. Restaurant and beauty templates can use phone, email, WhatsApp, or external booking links, which open the relevant external channel. A call, email, or WhatsApp message is an enquiry, but not by itself a confirmed reservation.

QREasy does not provide a native customer contact form, submission inbox, appointment scheduling, calendar availability, ordering, checkout, payment processing, automated confirmations, or property CRM. These limits apply to QREasy, not services the client may offer independently. An external provider may confirm bookings under its own rules. A consultant can still offer scheduling or payment through its own established process, so describe and link that process accurately.

For sector-specific prompts, use the restaurant website checklist before sharing a menu QR and the beauty website checklist for client questions, then adapt each route to the actual business.

Phone number and response owner
Email address and monitored inbox
WhatsApp number and message owner
Booking link and confirmation owner
Separate form link and provider

Check the plan and publishing handover

Check the selected plan against the proposed sites, pages, and QR codes. Review the current QREasy plans and allowances with the client, record the chosen plan, and date the decision so later changes are not mistaken for original requirements.

Plan the handover as well as the build. Arrange approved sections, publish the editable QREasy website, and verify that the same website address shows updated content. Website access needs an internet connection. Assign ownership for editing, link checks, and republishing after launch.

Free: EUR 0.00 monthly or annually; 1 website with up to 1 page, 1 dynamic QR code, unlimited static QR codes, and 7 days of analytics history. Contact Wallet cards are included; website-linked Wallet cards need Lite SME or Business.
Lite SME: EUR 2.99 monthly or EUR 28.70 annually; 3 websites, up to 4 pages each, 50 dynamic QR codes, unlimited static QR codes, and 90 days of analytics history. Website-linked Wallet cards are included.
Business: EUR 9.99 monthly or EUR 95.90 annually; 33 websites, up to 10 pages each, 357 dynamic QR codes, unlimited static QR codes, and 90 days of analytics history. Website-linked Wallet cards are included.
Confirm page, site, and dynamic QR demand fits before approval
Assign editing, link-checking, and republishing ownership

Review the QR journey and approve

Review the QR-to-browser journey as a separate acceptance test. A website-linked Wallet card requires Lite SME or Business, and its QR encodes the website URL. Scanning opens the site in the phone browser; it does not run inside Wallet. Google Wallet also includes a Visit Page link. Opening the website does not depend on a mandatory card-review step.

Choose the QR type based on how its destination must change. A static URL QR keeps a fixed encoded URL, while content at that URL can change without reprinting, including a hosted webpage or a PDF replaced at the same URL. Changing the encoded URL requires a new static QR. A dynamic QR uses a managed redirect whose destination can change without reprinting, subject to plan limits. Editing a hosted website does not require a dynamic QR.

Use the QREasy QR code generators after the destination and plan are settled, and keep static URL QR codes distinct from embedded static vCard data. Neither type guarantees scanning on every device. Test the handoff by scanning, opening the published site, checking navigation and links, and confirming that the displayed address matches the approved one.

Confirm the exact destination before generating the code
Test the code on the client’s intended devices
Verify the browser route and published navigation
Check updated content at the same URL
Record who replaces and retests the QR