WordPress Asset Request Intake Checklist Before Payment

A WordPress asset request should not start with payment.

It should start with confirmation.

Many website owners ask for a theme, plugin, template, or readymade design because they saw a demo and liked the look. That is normal. But a demo is not the whole project. The asset may need a license. It may need installation. It may depend on WooCommerce, Elementor, PHP version, hosting limits, plugin compatibility, images, copy, payment gateways, or custom setup.

If those details are not checked before payment, the buyer may expect one thing and the delivery team may be preparing something else.

A WordPress asset request intake checklist makes the request clear before money, delivery, setup, or handoff.

This is especially important for marketplace-style delivery where the customer may request a premium WordPress theme, plugin, readymade website design, or setup service through a support desk such as ThemeHub.

Direct Answer

A WordPress asset request intake checklist confirms the exact theme, plugin, template, or design requested; the buyer's website type; license condition; allowed site count; update/support terms; setup requirement; hosting environment; WordPress/WooCommerce/page-builder compatibility; demo-content needs; customization scope; delivery timeline; payment path; handoff evidence; and post-delivery support boundary before payment. The goal is to prevent wrong purchases, unclear license expectations, failed installs, and support disputes.

1. Identify The Exact Asset

Start with the exact asset, not a vague category.

Record:

• asset name
• asset type
• product URL or catalog URL
• demo URL
• vendor or author name
• version, if known
• category
• price or quoted amount
• whether it is free, premium, agency-license-backed, or custom

Asset types may include:

• WordPress theme
• WordPress plugin
• WooCommerce add-on
• Elementor widget pack
• readymade website design
• Next.js template
• HTML template
• landing page template
• admin dashboard template
• setup/customization service

Do not accept:

I want a business theme.

Ask:

Which exact theme or demo do you want, and for which website?

This prevents the first delivery mistake.

2. Confirm The Customer Website Context

The same asset can be perfect for one site and wrong for another.

Ask:

• What type of website is this?
• Is it a new site or existing site?
• What is the domain?
• Is WordPress already installed?
• Is WooCommerce needed?
• Is Elementor, Gutenberg, WPBakery, or another builder already used?
• Is there an existing theme?
• Are there important existing plugins?
• Is the site multilingual?
• Does the site handle payments, bookings, memberships, courses, or customer accounts?
• Is the buyer technical or do they need full setup?

This context decides whether the request is a simple asset delivery or a setup project.

A restaurant theme for a new site is different from installing the same theme on a live WooCommerce site with orders, caching, custom checkout, and existing SEO pages.

3. Confirm License Condition Before Payment

License expectations must be clear before payment.

Confirm:

• who owns the license
• whether vendor license is direct or agency-managed
• number of allowed sites
• update period
• support period
• renewal requirement
• staging-site allowance
• whether files can be redistributed
• whether the buyer receives direct vendor account access
• whether ThemeHub/setup desk only provides delivery/setup under a specific license condition

Do not use language that sounds like unlimited ownership unless the license really allows it.

Safe wording:

License coverage and delivery method will be confirmed for this exact item before payment.

Risky wording:

Buy once and use anywhere forever.

Many disputes start with license assumptions.

4. Confirm Whether Setup Is Included

Asset delivery and setup are different.

Asset delivery may mean:

• file access
• download link
• license key or activation path
• basic instructions
• vendor documentation reference

Setup may mean:

• install WordPress
• install theme/plugin
• activate license
• import demo
• configure required plugins
• set homepage
• check mobile layout
• connect forms
• configure WooCommerce basics
• test one lead or checkout path
• document handoff

Customization may mean:

• edit colors
• replace logo
• replace images
• add real copy
• build extra pages
• adjust sections
• connect WhatsApp
• configure SEO basics
• improve speed
• migrate content

Before payment, define which level the customer is buying.

If the customer expects a finished website, do not sell only a theme file.

5. Check Hosting And Technical Requirements

Many WordPress asset problems are hosting problems in disguise.

Check:

• WordPress version
• PHP version
• memory limit
• upload limit
• SSL status
• server timeout limits
• database access
• file permissions
• current theme/plugin count
• backup availability
• staging environment
• cache/CDN setup
• WooCommerce version, if relevant

For a business site, installation should not happen blindly on production without knowing backup and access status.

If the asset needs higher memory, a newer PHP version, or WooCommerce compatibility, the buyer should know before payment.

ThemeHub can connect setup/support paths through Hostao where applicable, but the scope must be stated before work starts.

6. Confirm Demo Content Expectations

A demo is not the customer's real website.

Before payment, ask:

• Do you want exact demo import?
• Do you already have logo, text, images, products, services, and contact details?
• Should demo content be removed?
• Who writes real page copy?
• Who replaces images?
• Who configures menus?
• Who sets forms?
• Who checks mobile?
• Who checks SEO metadata?

Demo imports often look good because they use polished images and dummy text.

A buyer may be disappointed if the final site still contains placeholder content or looks empty after demo removal.

Set the rule:

Demo setup is not the same as final business content setup unless content replacement is included.

7. Confirm Plugin Dependencies

Themes and templates often depend on plugins.

Check:

• required plugins
• recommended plugins
• premium dependency plugins
• page builder requirement
• WooCommerce requirement
• form plugin requirement
• slider/gallery dependency
• custom post type dependency
• security/cache compatibility
• whether dependencies are included in the price

If a theme demo needs a premium builder add-on, the buyer should know before payment.

Do not let "theme price" hide required plugin cost or setup complexity.

8. Confirm Customization Scope

Most buyers say they need "small changes."

Small can mean many things.

Define:

• logo replacement
• color change
• font change
• menu setup
• homepage section edits
• contact form setup
• WhatsApp button
• product upload
• service page creation
• blog setup
• payment gateway setup
• shipping/tax setup
• custom code
• speed optimization
• SEO setup

Then classify:

• included
• optional add-on
• not included
• needs custom quote

This is the cleanest way to prevent scope drift.

If custom work is not priced before payment, the buyer may assume it is included.

9. Confirm Delivery Timeline

Delivery timing depends on the request.

Record:

• payment confirmation time
• license confirmation time
• asset availability time
• setup start time
• customer access handoff time
• content required from customer
• revision window, if any
• support window

A simple asset request may be quick.

A setup project may depend on hosting access, domain access, logo, copy, images, payment gateway credentials, and customer approvals.

Do not promise instant delivery when the item needs license confirmation or setup review.

10. Confirm Access Needed

If setup is included, confirm access before starting.

Possible access:

• WordPress admin
• hosting/cPanel
• domain/DNS
• FTP/SFTP
• database backup path
• WooCommerce admin
• payment gateway credentials
• email SMTP
• Google Analytics/Search Console, if relevant
• logo and brand assets
• existing theme/plugin list

Use secure access handling. Do not collect credentials casually in public threads.

If access is not available, classify the request as guidance-only or file-delivery-only until access is provided safely.

11. Confirm Support Boundary

Before payment, explain what support covers.

Support may include:

• delivery question
• installation help
• activation guidance
• basic setup issue
• one visible error after install
• handoff explanation

Support may not include:

• unlimited customization
• vendor-level bug fixing
• hosting migration
• hacked-site cleanup
• checkout/payment approval
• legal/privacy copy
• custom plugin development
• months of updates
• performance guarantee
• SEO ranking guarantee

This boundary protects both buyer and support team.

The buyer knows what they are paying for.

The support team avoids becoming responsible for every future WordPress issue.

12. Confirm Payment Path And Proof

Payment should happen only after the request is clear.

Before payment, confirm:

• exact item
• exact price
• setup add-ons
• license condition
• delivery method
• timeline
• refund/cancellation rule, if any
• invoice/receipt path
• support contact

After payment, record:

• payment confirmation
• item delivered or setup started
• license/setup status
• files or access shared
• handoff note
• support period

Do not let the customer pay for an unclear request.

Clarity before payment is cheaper than dispute resolution after payment.

Copy-Paste Checklist

Use this before accepting a WordPress asset request:

• Exact asset name is confirmed.
• Product/demo URL is recorded.
• Asset type is identified: theme, plugin, design, template, setup, or service.
• Customer website type is confirmed.
• New/existing site status is confirmed.
• WordPress/WooCommerce/builder requirements are checked.
• License condition is confirmed before payment.
• Allowed site count and update/support period are clear.
• Direct vendor access versus agency-managed access is explained.
• Delivery-only versus setup versus customization is defined.
• Hosting and technical requirements are checked.
• Backup/staging need is noted.
• Demo import and content replacement expectations are clear.
• Required plugins and dependencies are listed.
• Customization scope is marked included/add-on/not included.
• Timeline depends on asset availability, access, and customer content.
• Required access is listed.
• Support boundary is stated.
• Payment path is confirmed after scope clarity.
• Handoff evidence will be recorded after delivery.

Buyer Example

A customer asks:

I want the ShopEase theme for my online store. How much?

A weak intake replies with only a price.

A strong intake asks:

• Is this a new store or existing WooCommerce site?
• How many products?
• Do you need payment gateway setup?
• Is hosting already ready?
• Do you need exact demo import?
• Do you have logo, images, categories, product copy, and policies?
• Do you need only the theme or full setup?
• Should ThemeHub confirm license condition and setup availability before payment?

After the intake, the request becomes:

Customer wants ShopEase for an existing WooCommerce store with 80 products. Needs theme installation, demo-style homepage, payment gateway check, mobile review, and basic handoff. Customer has hosting and products but needs copy/image cleanup. License condition and setup scope must be confirmed before payment.

Now payment can be tied to a real scope.

That is better for the buyer and the delivery team.

Final Takeaway

Theme and plugin buying fails when the buyer pays for a vague expectation.

The safer path is to confirm the exact asset, license condition, website context, setup need, technical requirements, demo-content expectation, customization scope, timeline, support boundary, and handoff evidence before payment.

That turns a risky "send me this theme" request into a professional delivery workflow.

For small businesses, that clarity matters more than a flashy demo.