# Should a website service page list projects it does not accept? How to help customers assess suitability

Source: https://www.jvds.cn/en/share/website-design/service-project-fit-boundary
Language: en
Published: 2026-10-08
Author: JVDS Design Studio

A service page can describe projects it does not accept, but should help customers understand the criteria rather than present a rejection list. The most useful service boundaries distinguish work already outside business scope from cases where insufficient information prevents judgment. These need different responses. Combining them under “please contact us” makes the boundary ineffective.

The company should confirm actual scope before adjusting wording. The website cannot decide what the business team accepts, and “not currently arranged” should not become “technically impossible.” Accurate scope helps suitable customers prepare materials and uncertain customers understand how to explain further.

## Give different responses to explicitly excluded work and unresolved conditions

Explicit exclusion means the company has decided not to provide a task, such as a service type outside its existing business. Unresolved conditions mean information about the item, scope or dependencies is insufficient for judgment. The first can be stated directly; the second should identify additions needed instead of giving an affirmative or negative answer prematurely.

Organize requirement categories that can currently be confirmed rather than invent every possible project. Ask business owners to state actual handling for each: accepted, requiring checks or currently not accepted. This internal exercise prepares wording. Public pages show conditions relevant to customer judgment without publishing every departmental opinion or internal score.

“We do not do overly complex projects” is unclear because customers cannot tell what complexity means. “We currently do not provide on-site construction and only discuss the product supply scope identified in the materials” is easier to understand. Specific wording must come from actual company arrangements; this example illustrates wording rather than establishes business scope.

If a limit arises from a current condition, identify that condition. For example, if actual service covers only confirmed regions, state those regions rather than generalize that every out-of-region requirement is unsuitable. Additional future resources are future arrangements; without plans, the page should not suggest imminent availability.

Use “requires further checking” for insufficient information. When customers can provide task background but lack a complete solution, identify what affects assessment before deciding next steps. Calling unknowns excluded may prevent discussable requirements from being explained; calling them universally accepted creates false expectations.

![Miniature scene checking service scope through subjects, tasks and conditions](https://www.jvds.cn/upload/2026/1004/1791059225862-725950.webp)

## Every boundary should identify a subject, task or condition

The subject explains what the service concerns: a product type, project or work stage. The task explains the work performed: design, development, organization, installation or other specific activity. Conditions explain prerequisites, such as usable materials, clear scope or supporting roles. Boundaries need not contain all three, but should at least help customers locate their requirements.

For example, suppose a team develops websites from existing designs. Implementing development and also replanning and redesigning every page are different tasks. The website can explain the current discussion scope separately rather than assume suitability because both sides say “build a website.”

Some limits concern materials. If confirmed product information is needed, explain the judgment it supports and whether initial materials checking is possible without it. Do not say “complete materials required” while leaving the minimum meaning of complete unexplained, making customers guess and prepare large numbers of files.

Scope should also exclude associated tasks easily assumed to be included. Product supply may not include on-site service, design completion may not include development, and webpage production may not include long-term content operations. Explicitly describing these relationships helps customers compare needs better than a generic “extra work excluded.”

Boundaries are not assessments of customer quality. Avoid language such as “only high-quality clients” or “no low-end requirements.” Focus on task suitability and prerequisites. Customers may have reasonable needs the current team simply does not provide. Accurate explanation needs no value judgment about them.

## Place unsuitable cases near the related tasks

Exclusions hidden in a footer may leave customers assuming the whole service is included after reading the page. Put key boundaries near relevant service tasks so visitors see them while forming expectations. For example, near an implementation-service description, explain the actual responsible stage and parts needing other roles’ participation.

Match explanation length to the risk of misunderstanding. A simple boundary needs one clear sentence; a task dependent on several conditions needs further explanation. Do not pile up “excluded” and “depending on circumstances” without specific subjects, or remove important limitations into vague disclaimers merely to seem friendly.

Organize by customer requirements rather than internal service codes. Customers think “I have an old website and want to migrate content” or “I have complete designs and need development.” Internal service names alone do not identify relevant boundaries. Actual task descriptions connect requirements with scope and support initial judgment.

Whether excluded tasks receive alternative contact suggestions depends on actual company arrangements. Do not recommend unconfirmed partners just to appear helpful, or call a task impossible to explain the company’s refusal. Stating current supply scope is usually accurate enough.

Where needed, distinguish current scope from work available for separate evaluation. “Available for separate evaluation” is appropriate only when the company actually accepts it, rather than a universal ending to every exclusion. Readers should understand which questions can continue and which identical requirements need not be submitted again.

![Miniature scene adding background when conditions are incomplete to continue assessment](https://www.jvds.cn/upload/2026/1004/1791059225862-284129.webp)

## Give uncertain customers a route toward further judgment

An inquiry route for unknown requirements should identify missing background rather than make customers reach professional conclusions first. Ask them to describe the task, what exists, what is missing and influencing conditions. Relevant personnel then explain whether further evaluation is needed.

Suppose a customer knows only that the current website is hard to maintain and cannot decide between local adjustments and a complete redesign. The page can ask for the existing URL, actual editing difficulties and desired responsibility scope. Do not require a guessed technical solution or a guarantee that page count will remain unchanged merely to choose a package.

Some pending conditions require third parties or internal specialists to confirm, such as public product facts, existing system materials or design-file usability. The route can record current gaps and the roles able to supply them. Customers should not have to turn “not yet obtained” into “available” to begin communication.

Describe next-step outcomes accurately too. Submitting requirements usually begins scope checking rather than commits the company to accept work or provide a full quote. Explain the conditions to discuss. Publish response timing only when actual arrangements support it, rather than copy an unenforceable fixed deadline.

Retain an explanatory contact method for people who read the boundaries but still need confirmation. They may be unsure whether their task falls within a limitation. Allowing specific questions is more useful than repeating “we do not accept this project type.” This does not reopen business explicitly excluded.

## Test wording with boundary cases rather than only whether it sounds pleasant

Prepare three hypothetical requirements: clearly within scope, clearly outside it and missing a key condition. Ask someone unfamiliar with the service to read the page and explain their next action for each. If all three conclude they should submit complete requirements first, boundaries may remain unclear.

For definitely unsuitable work, test whether readers identify a specific reason rather than feel their project is insufficiently prestigious. For insufficient conditions, check whether they know what to add rather than believe they are rejected. These different explanations are the focus of this review.

Have actual customer-facing personnel check public wording. If the page accepts work staff must first exclude, or says work is never offered although the team can evaluate it, the website and business disagree. Align scope facts before discussing style. See [How to Design a Corporate Website for B2B Services](https://www.jvds.cn/en/share/website-design/b2b-service-website-multi-stakeholder-design) for related checks.

Business changes also change boundaries. Maintainers should know who confirms acceptance scope and which service pages and contact prompts are affected together. Updating only the main service introduction while old FAQs retain opposite claims leaves customers unsure which statement applies. See [How to Design a Corporate Website Service Page](https://www.jvds.cn/en/share/website-design/service-page-design-guide) for related checks.

Successful service-boundary wording lets readers distinguish unsuitable work, insufficient information and matters open for discussion, with customer-facing staff recognizing those conditions. Boundaries reduce misunderstanding and support preparation. Clear actual tasks provide more judgment value than a vague promise to do anything.

![Miniature scene reviewing three boundary requirement types against actual acceptance scope](https://www.jvds.cn/upload/2026/1004/1791059225862-215952.webp)

## Frequently asked questions

### Does listing excluded tasks make the company look less professional?

It depends on accuracy. Explanations based on tasks and actual scope help customer judgment. Belittling customers or using unclear conditions leaves boundaries without a professional basis.

### Can “it depends” cover every special requirement?

It is not recommended. At least explain which conditions affect assessment and what information is needed. “It depends” without an actionable checking route cannot guide the next step.

### If resources are temporarily unavailable, should the page say the task is never accepted?

Do not turn a current arrangement into a permanent conclusion. Describe confirmed present facts and update them after changes. Without clear plans, do not promise a future opening date either.

### Can customers with requirements outside public scope still ask questions?

If the company actually provides scope checking, allow specific questions. Asking does not mean acceptance; clarify the item and conditions first.

### Can an unclear budget be described immediately as unsuitable?

Check whether budget actually determines current acceptance. Do not invent unconfirmed thresholds. Explain requirement scope and pending conditions first rather than guess amounts for customers.