Streamlining Project Intake with a Simple Workflow

Project intake is the moment a service business decides whether a customer request is clear enough to become a responsible commercial proposal or a scheduled job. In small teams, the initial information often arrives through email, telephone or a conversation with an account manager. The person receiving it may understand the customer but overlook a technical dependency, a necessary site check or a conflict with another commitment. A simple intake workflow can protect both sides by collecting essential facts, exposing uncertainty and confirming who may approve the next step.

Intake is different from project delivery. Delivery manages authorised tasks after an agreement; intake establishes whether the business understands the request well enough to quote, decline, defer or begin a clearly permitted preliminary assessment. A CRM record can help, but the quality of the process depends on a short useful checklist and an accountable human decision. This guide concentrates on the period before the project is accepted, when an inaccurate assumption is still relatively cheap to correct.

Capture the request once and preserve its source

A request may originate from a website form, referral, shared inbox, telephone call or existing account discussion. Give every material request a unique identifier, record when it arrived and retain the customer's description. Do not force the prospect to resubmit the same information into a separate portal merely because the business uses a different system internally. A staff member should be able to create a record from a call with appropriate attribution.

Keep a minimum set of fields: intended outcome, relevant product or service, location if necessary, contact, desired timeframe, known constraints and the employee responsible for clarification. Missing detail should be labelled unknown rather than filled with invented values. An approximate quantity or hoped-for start date must not become a confirmed project requirement simply because an integration expects a number.

Check for existing records conservatively. The same customer may ask for two unrelated projects, while similar company names may belong to different organisations. Preserve separate requests and link them only where evidence supports the relationship. Record the source channel so a colleague can find the original words if the summary is ambiguous.

Clarify desired outcome before choosing a solution

Ask what the customer wants to achieve, what currently prevents it and what a successful result would look like. Someone requesting 'a new system' may primarily need reliable reporting, faster booking or compatibility with equipment already in use. Understanding that purpose helps the team avoid quoting an unsuitable package. The employee should distinguish the customer's stated requirement from an internal suggestion.

Use context-sensitive questions. A maintenance project may require asset model, site access and service history; a consultancy assignment may require stakeholders, deliverables and decision dates. Avoid one enormous questionnaire that treats every job as identical. A short initial discovery conversation can identify which specialist should ask the next questions.

Document exclusions and uncertainties. If the customer cannot confirm a technical interface, create a verification task rather than promising integration. Where evidence is necessary for a credible proposal, explain why it matters and how the customer can provide it. The next step should reduce uncertainty, not simply move the record to a more impressive CRM stage.

Check commercial and operational fit separately

A customer's need may fit the company's services but fall outside current capacity, geography or available skills. Check these dimensions honestly. A job may be technically feasible but impossible within the requested deadline, or commercially attractive while requiring a specialist the team does not have. Record which dimension needs review and who can make the decision.

Separate suitability from urgency. A high-pressure message about an ordinary service does not automatically justify displacing another approved commitment. Conversely, an understated description may conceal an important safety or continuity issue that needs specialist attention. Use established escalation procedures where necessary and do not let a sales qualification rule override them.

Consider whether the customer has an existing agreement covering the requested work. A routine support request should not be turned into an unnecessary new project quote. Where an existing contract or order might apply, link to the authoritative source and ask the appropriate person to verify scope.

Confirm what information is needed for a meaningful estimate

Before asking staff to produce a quotation, agree the minimum facts for the service: deliverables, assumptions, dependencies, location, expected customer input and any important technical constraints. For a straightforward repeat task, a brief checklist may suffice. Complex work may require a site visit, discovery workshop or trial. The level of investigation should match the consequences of a wrong estimate.

Do not disguise a rough estimate as a fixed accepted price. If key assumptions remain open, label the proposal accordingly and identify what must be confirmed before commitment. Preserve the evidence used for effort, materials and timing. A customer can then understand why a quotation might change when previously unknown facts are discovered.

Give technical and delivery reviewers the original problem description and proposed boundaries. They should be able to request clarification, flag a risk or indicate that the job is not ready for quotation. Avoid a hand-off that simply copies a salesperson's optimistic summary into a delivery task list.

Route specialist questions with a named owner

Intake often crosses sales, operations, engineering and finance. Each contribution needs a specific question and a responsible person. A technical colleague may be asked to check compatibility, while finance reviews credit terms or a manager approves unusual commercial conditions. The overall intake coordinator remains responsible for bringing the answers together.

Make blocked information requests visible. A task waiting for a site photograph should show who asked, which customer contact received the request and what happens when it arrives. Do not classify a case as internally delayed when the team has not clearly requested the information. Likewise, do not leave a supplier query indefinitely with an unmonitored external mailbox.

Set sensible reminders, not a flood of alerts. When a specialist is absent, reassign the work with the original context. Keep confidential commercial and personal data accessible only to people who need it for the decision. A CRM record should coordinate the hand-off without copying sensitive documents indiscriminately.

Use explicit outcomes instead of forcing every enquiry into delivery

Intake should end with a meaningful decision: ready to quote, needs investigation, outside the business's scope, deferred at the customer's request, declined with explanation or authorised to proceed under a confirmed agreement. Each status has different consequences. A deferred project is not lost; a declined project should not generate a delivery schedule. A provisional technical assessment is not permission to begin all work.

Document who may authorise unusual commitments and the evidence required. If the customer accepts a proposal subject to changes, preserve those conditions. The business should only release downstream tasks when the necessary commercial and operational gates are met. Keep accepted scope and later changes versioned so staff do not rewrite the original request to match what eventually happened.

Communicate the outcome clearly. A responsible decline can preserve trust if the business cannot meet a requirement. A request for more detail should tell the customer precisely what is needed. Avoid saying the work is scheduled when the intake decision remains conditional.

Hand over accepted work without making customers repeat themselves

When a project is approved, transfer the relevant intake pack: customer identity, verified scope, accepted terms, dependencies, delivery constraints, relevant contacts, known risks and open clarification tasks. Link to the source agreement and notes. Do not create a second project record that loses the original enquiry or forces the delivery team to reconstruct the accepted promise from private email threads.

Define the downstream owner and a point of acceptance of the hand-off. The receiving team should confirm that the scope is understandable and that prerequisites for scheduling are known. If crucial information is missing, return the matter for clarification before making a customer-facing commitment. Avoid interpreting a task created by software as proof that the receiving person accepted responsibility.

Keep systems of record distinct. CRM can own opportunity context, project software can own delivery tasks and accounting can own issued invoices. Use stable links and controlled events rather than copying live financial data into a standalone spreadsheet. Test an integration retry to ensure a single accepted project does not create two jobs.

Pilot realistic incomplete requests and improve the questions

Prepare sample cases for a standard repeat job, unfamiliar complex request, missing site details, unsuitable geography, existing support entitlement, supplier dependency and a changed customer requirement. Write the expected next action for each before testing the workflow. Ask an employee who was not involved in configuration to find the request and explain why it is or is not ready for quotation.

Measure quotations returned for missing information, technical rework after acceptance, unowned clarification tasks, duplicated customer records and unnecessary back-and-forth with the buyer. A lower volume of quotes is not automatically bad if the business has avoided making inappropriate promises. Equally, a long intake form is not successful simply because it captures more fields.

Use the results to shorten unnecessary questions and strengthen the few critical checks. A small company may need only a shared request register, a short service-specific checklist and named reviewers. Add automation where repeated hand-offs create genuine errors. A dependable intake workflow lets the team understand the proposed work before it commits to deliver it.