An Agency Workflow from Enquiry to Handoff

An agency project workflow should carry the client commitment into a project, assign the next actions, make review decisions visible, and finish with a clear handoff. Start with the records and decisions people actually need. Add stages only when they change ownership or explain what happens next, rather than copying another agency's process.

Where should the workflow begin?

Begin before the first delivery task. An enquiry creates information about the client, the requested outcome, timing, and assumptions. If delivery starts without that context, the team has to reconstruct the promise. The workflow should identify which facts are agreed, which are provisional, and where the current scope reference lives.

Keep the sales decision separate from the delivery plan. A won opportunity is a reason to prepare the engagement, not proof that every detail is ready. The delivery owner still needs to review scope, client inputs, dependencies, and capacity. A handoff can be short while still giving someone responsibility for this check.

Choose a small set of records to connect: lead, client, scope reference, project, work items, review decisions, and final resources. A single engagement may need several documents or milestones, but it should not require several incompatible descriptions of who owns it. Clarify the relationships before deciding which view to use on a dashboard.

Which stages need a clear handoff?

Use a stage when the next action or responsible person changes. For example, the person qualifying an enquiry may hand over to someone preparing scope, then to a project owner. Review can shift responsibility to an internal reviewer or the client. The stage name should help the team understand that change rather than merely describe elapsed time.

These are process moments, not a claim that every product lets you create arbitrary workflow states. Match the operating process to the supported model in the software. Where a tool has fixed states, use documented records and conventions rather than pretending the state engine can be redesigned without limits.

How do tasks become usable assignments?

Write the outcome of the task, not just the activity. “Prepare draft homepage copy for review” gives someone a deliverable and a review purpose. “Website work” does not. Identify an owner, a due date when relevant, and the inputs needed to begin. Link the scope or supporting document rather than copying conflicting summaries.

Separate the owner from people contributing or reviewing. One person should know they are responsible for moving the next action forward, even when several people help. If the work is too large for a useful next action, break it down. Avoid using a long checklist to hide several deliverables with different owners and review needs.

Use estimates as planning inputs with uncertainty. A precise number does not make a task understood. Revisit effort when new information changes the work, and record the decision if it affects the client commitment. Work logs can inform later review, but recorded hours alone do not prove business value or margin.

When should an agency use sprints?

A sprint can help when a team plans a defined set of work over a shared window. It gives a useful moment to review scope, capacity, and unfinished items. It can also add ceremony if a freelancer or small project only needs a few dated tasks. Choose the planning rhythm that helps people make decisions.

If you use sprints, agree what enters the window and how urgent additions are handled. New work should not silently increase the commitment. Record what moves out, why, and whether a client-facing milestone changes. This makes the tradeoff understandable to people outside the daily planning conversation.

At the end, review completed and unfinished work without treating a fixed percentage as a universal health score. Ask what blocked progress, which assumptions were wrong, and what action would improve the next cycle. Keep the improvement small enough to follow through. A retrospective is useful when it changes a decision, not because it fills a recurring slot.

What belongs in a client update?

Publish the information a client needs to understand the engagement: the current outcome, next milestone, decision or input required, and any agreed change. Internal task discussion may be important to the team but unnecessary or confusing for the client. Decide who turns maintained delivery records into an appropriate client-facing summary.

Keep the source current. If the client update says a milestone is waiting for feedback, record which feedback, who can provide it, and what happens next. Avoid vague status labels that require a call to interpret. A clear update can make a later conversation more useful by leaving time for decisions rather than reconstruction.

Do not assume the client sees every change automatically. Verify the product's sharing behavior and explain what is visible. In a portal, shared summaries and documents may be a narrower view than internal work. That boundary is useful when it is intentional, maintained, and explained to the people using it.

How do changes enter the workflow?

Capture the requested change, identify the current scope reference, and discuss the effect on effort, dates, dependencies, and commercial terms. Then record who authorized the decision. This operational sequence does not replace the actual agreement, but it gives the team a way to avoid scheduling extra work before the tradeoff is understood.

For a small request, the record can be brief. The important parts are the request, decision, and next action. Do not make a client complete a large form for every clarification. Equally, do not let several small requests accumulate without anyone noticing that the original plan no longer describes the work.

Return the result to the project. Update the relevant tasks and dates after the decision, and make the current scope easy to identify. A change recorded only in a message may be forgotten by someone joining later. Link the decision to the work that implements it so the team can explain why the plan changed.

How should the engagement end?

Use a handoff checklist for final deliverables, access, instructions, open issues, and the next owner. Distinguish delivery from acceptance and both from payment status. A completed task is not automatically a client approval, and an invoice is not evidence that money has arrived. Keep each record tied to the appropriate decision.

Review access after the handoff. Some resources may remain shared for maintenance or support, while other permissions should change. Document the actual ongoing scope rather than implying unlimited support. Tell the client where to ask a question and which materials are final so the engagement has an understandable stopping point.

In Flotick, evaluate lead management, client-linked projects, documents, and the client portal as one engagement. Start free with a real workflow, check the plan limits, and expand only after the handoffs are clear to the people using them.

What questions should a team settle?

How many workflow stages do we need?

Enough to explain the next action or change in ownership. More stages are not inherently better. Keep the process understandable and respect the supported states in your tool.

Do all agency projects need sprints?

No. Use sprints when a shared planning window helps. Individual tasks and dates can suit simpler delivery work.

Does linking a client and project replace a sales handoff?

No. It keeps records connected, but someone still needs to review the scope, dependencies, and first delivery actions.