Start a web-to-print project brief
-
Home
-
Start a web-to-print project brief
Start a web-to-print project brief
The form below has six short steps
The project brief form on this page walks through six steps: the service it is about (preselected when you arrive from a service page, or left for you to choose), your situation, the brief itself, timing and any files involved, your contact details and consent, then a summary to confirm. The steps are a convenience for reading the form a section at a time; with JavaScript turned off, every field still appears as one page, in the same order, so the form works either way. Every field carries a visible label, and a field left blank or filled in incorrectly is reported next to that field, not only at the top of the page.
Choosing "Not sure — help me choose" instead of a specific service is a normal, complete answer: say what you are trying to achieve in the brief itself, and a discovery conversation can place it. The timing step accepts a plain-language description of any files you expect to discuss (there is no upload yet, see the privacy notice) and an optional preferred call window, such as a weekday band and time zone, if an initial call seems like the right next step. Submitting the form does not create an account and does not start a priced order; nothing you send here is published.
Describe the constraint, not a feature list
A useful brief starts with an example. Choose a product a customer can order today, or should be able to order. Describe its permitted sizes, materials, quantity rules, finishing and artwork requirements. Then show the point at which the current software stops representing the business correctly. A screenshot or redacted specification can help, but sensitive files should not be sent before an appropriate channel is agreed.
If the problem is in pricing, include a known-good estimate and the inputs behind it. If it is in print output, describe the required file and the rejection reason. If it is in the order handoff, identify the receiving MIS, ERP or scheduler and whether it offers a documented interface. If you do not know, write that. An unknown interface is a scoping question, not a reason to guess.
What to include
Choose the nearest starting point: new setup, upgrade, migration, integration, maintenance assessment or an AI use case. Publishing and marketing teams can describe the content and approval path. Printing businesses can describe estimating, artwork and production. Enterprise teams can describe who orders, who approves and which systems must receive the result.
State who will use the system: retail customers, trade accounts, internal buyers or production staff. Name the systems that must remain in place. Tell us what cannot change, such as an existing approval chain, an established job identifier or a prepress workflow. Describe what you would accept as evidence that the new behaviour works. A small sample set of real orders or quotes, anonymised where needed, can become the basis for that acceptance test.
You do not need to provide a budget number through this page. The brief is for technical qualification, not a public estimate. It also should not contain live credentials, customer personal data or unrestricted artwork files.
Include the person who can confirm a correct result on your side. A pricing rule may be approved by an estimator, while an output file needs prepress review and an order handoff needs production review. One broad sign-off at the end can hide disagreement among those roles. Identifying them early helps turn a vague request into checks against real work.
What happens after submission
A brief gives us a basis for deciding whether a scoped discovery conversation is appropriate. Include any deadline and the event behind it so timing can be assessed.
An initial conversation can identify what is understood, what must be inspected, and whether the next useful step is a bounded discovery engagement, a more specific question, or a recommendation to use a packaged product. The output of a discovery engagement is written so that a supplier other than us can execute it.
The how we work page explains scope and acceptance. Read when not to hire us if your requirement is standard or time to first order is the main decision. The service list helps you name the engineering area, but the brief should stay anchored to your actual workflow.
Frequently asked questions
Do I have to pick an exact service before I start? No. "Not sure — help me choose" is a complete answer for the service step; the brief itself is what gets your request placed correctly.
Can I attach files here? Not yet. Describe any file or export you expect to discuss in the timing step, in plain language, and a suitable exchange route is agreed afterwards. See the privacy notice for how a brief is stored.
Will I see a price on this page? No. This form is for technical qualification, not a published estimate; a scoped quote, when one applies, is handled through a separate, non-public channel.
What happens if I submit the same brief twice? A second submission with the same email address, service and brief text within a day is recognised as the same request rather than treated as a new one.
Send your project request
Describe one real product or workflow and the result you need. Do not include credentials, private customer data or confidential artwork.