For web design agencies
Ship the site, then keep the relationship
Build projects are finite and clients are not. The money is in what happens after launch, and that only works if the client can see what they are paying for each month.
The problem
What actually slows you down
Not the work itself — the administration around it.
- Every project stalls on client feedback
- Not because they are difficult, but because 'waiting on you' lives in an email thread nobody owns. Put it on the board with a due date and the client can see it in their portal — the nudge stops being your job.
- Scope creeps in conversation, not in writing
- Requests that arrive by text become tasks with a project and an owner, so 'while you're in there' is visible as extra work rather than absorbed silently.
- Every build repeats the same twenty steps
- Write the build once as an SOP with its checklist, then start it for each new project. Nobody rebuilds the launch checklist from memory, and nothing gets skipped because it was a Friday.
- Handover is a folder of links in an email
- Documents, credentials handover and deliverables sit against the client record, so the next person on the account finds them without asking.
- Retainers feel invisible after month two
- A portal showing uptime work, updates shipped and tickets closed makes the retainer legible. Silence is what gets a maintenance plan cancelled.
What you get
The parts that matter for this work
Project boards
Kanban per project with owners and dates, rolled up per client so you can see the whole book at once.
SOPs as task templates
Your build and launch process, written once and started per project in a click.
Support desk
Post-launch requests become tickets with priority and SLA tracking, not texts at 9pm.
Documents
Proposals, contracts and deliverables attached to the client instead of an email thread.
Website monitoring
Every client site watched by real-traffic heartbeat and 15-minute checks, with alerts when one goes down.
Invoices in the portal
The client sees what has been billed and what is outstanding where they see everything else.
In practice
From signed proposal to maintenance retainer
The build is the easy half. This is the rest of it.
- 1
Onboarding link
Get WordPress, hosting, domain, Google Analytics, Tag Manager and Search Console access in one link — your own steps for the platforms with no API, and never a password.
- 2
Start the build SOP
The project appears with every step already on it — discovery, design, build, QA, launch checks — assigned and dated.
- 3
Client sees progress
They watch the board move in their portal, and approvals are tasks with their name on them rather than unanswered emails.
- 4
Launch and hand over
Deliverables and credentials go to the client record. The handover is a place, not a message.
- 5
Roll into a retainer
The support desk takes requests, the portal shows what you did this month, and the invoice sits beside it.
Make the retainer visible
Set up your workspace, put one live project on a board, and give that client a login.
Connect the website project to the client relationship
Software for web design agencies needs to support more than a launch date. A website project begins with access, business information and a brief; it continues through design choices, content, development and approval; it often becomes a maintenance relationship. Keep those stages tied to the client so a support request after launch can be understood in the context of the original work. A folder of finished design files is useful, but it does not explain who approved the navigation or why a particular integration was chosen.
Define the project before building the board. List the agreed pages, content responsibilities, integrations, review rounds and launch dependencies. Identify the person who can approve work and the person who controls the domain or hosting. These may be different people. Agency Pilot can organise the client record, tasks, SOPs, documents and portal, while your delivery process establishes what each stage means. A structured project record is especially valuable when the designer, developer and account manager do not all attend the same calls.
Treat website access as a project dependency
Access should be requested for a specific job. Editing website content does not automatically require control of the domain, and reviewing analytics does not automatically require administrator privileges. Make an inventory of the assets the project depends on: CMS, hosting, DNS, analytics, tag management and any third-party service being changed. Record the owner and the required role for each. Supported account connections and guided website-access steps serve different purposes; a guided step still needs a person to follow and verify it.
Test access before scheduling the dependent work. Logging into a CMS is not the same as confirming that the correct site, staging environment and permissions are available. For an illustrative redesign, the developer may be able to edit pages but still need the client’s hosting administrator for a launch change. Record that dependency early, with an owner and expected response time. Keep credentials out of ordinary task comments and use delegated accounts wherever the platform supports them. A convenient project board should not become an informal password store.
Give approvals an observable finish line
An approval task should say what the client is reviewing and what decision you need. “Review design” leaves too much room for interpretation. A stronger instruction identifies the page or version, the deadline and the questions: is the service description accurate, is the navigation complete and may the team proceed to implementation? Explain how consolidated feedback should be supplied. If several stakeholders comment separately, name the client representative responsible for resolving their differences.
Record approval against the version actually reviewed. Later changes should have their own scope and decision instead of silently reopening the earlier sign-off. This protects the client as well as the agency: both can see what was agreed and what is new. The portal provides a place for clients to follow the project, but good task wording still matters. Distinguish waiting for feedback from development work in progress, and communicate the effect of a late response on the planned launch rather than treating every date as unconditional.
Prepare a launch checklist that can be reused safely
A reusable SOP is a starting point, not proof that every website has the same launch requirements. Keep the common checks, then add the specifics of the build. An ecommerce site, a brochure site and a site with a booking integration have different critical paths. Assign responsibility for forms, navigation, content accuracy, analytics validation, redirects where relevant and the client’s final approval. Your process should say what evidence confirms each check, not just provide a box to tick.
Plan who can make the launch change and who can respond if the result is wrong. Agree the communication window and preserve the information needed by the hosting or development team to restore the previous state. Agency Pilot organises the work; it does not replace deployment tooling or a tested recovery process. Once the site is live, validate the public experience and the business's important enquiry routes. A successful page load is only one part of a successful launch if the contact form still sends enquiries to the wrong recipient.
Make the maintenance retainer understandable
After launch, convert the relationship into the actual ongoing service the client purchased. Separate routine maintenance, new feature requests and incidents. A support ticket should identify the affected page, the observed problem, its impact and the contact who can help reproduce it. Avoid calling every request urgent. Agree how priorities are determined and how the client should report a business-critical problem. Website monitoring can highlight availability concerns, while an assigned person investigates what the alert means.
An illustrative monthly update could describe a repaired form, an approved content change and a pending plugin decision. Include what remains outside scope and what needs a quote. This is more useful than a vague claim that the website was maintained. Keep invoices, deliverables and support history associated with the client so a new team member can understand the relationship. Review the service periodically: a website that has added bookings or online sales may require a different maintenance agreement from the original brochure site.
Before rolling the process out across the agency, follow one project from intake to its first post-launch request. Ask the client whether they can find the current status, then ask a colleague whether they can identify the next action without asking the project manager. Revise confusing task titles and missing handover notes. This small operational check helps you improve the way the team works without claiming that a software subscription alone removes scope changes, client delays or the need for technical judgement.
Frequently asked questions
What should a web design agency configure first?
Create one client and one representative project with the agreed scope, key contacts and launch dependencies. Add only the stages your team can explain consistently. Starting with a complex template for every possible service makes adoption harder. Use the first project to learn which fields, documents and recurring steps your team actually needs before expanding the setup.
Can onboarding collect website and Google account access?
Agency Pilot combines supported platform-access workflows with guided steps for websites and other services. Specify what the client should grant and verify the resulting permissions. Do not assume a completed instruction means the developer can perform every launch task. Website platforms differ, so name the CMS, hosting service and relevant owner in your onboarding instructions.
How can we reduce delays caused by client content?
Put content responsibilities in the initial scope and assign clear deadlines before design depends on them. Identify whether the agency is writing, editing or simply placing supplied copy. A content task should name the page, format and approver. If content is late, explain the resulting schedule choice rather than filling the live website with unapproved claims.
What is the difference between feedback and approval?
Feedback proposes changes; approval authorises progression on an identified version or deliverable. Ask the client for the decision you need and record it in context. An informal comment such as “looks nice” may not settle factual accuracy, image rights or the launch decision. Define the approval process at kickoff so both sides understand its meaning.
Should every website build use the same SOP?
Use a shared core for repeatable tasks, then adapt it to the project. A shop needs different checks from a simple service website, and a migration needs dependencies a new domain may not have. Keep the reasons for exceptions visible. An SOP helps prevent omissions when its steps reflect the real work rather than a fixed universal list.
How should we manage a request that changes scope?
Record the requested change and its impact on effort, timing and agreed deliverables. Ask the authorised client contact to decide whether to add it, exchange it for another item or defer it. Keep this decision separate from ordinary corrections. A project system gives the request a place to live, but the commercial agreement still determines what is included.
Can clients follow project progress in the portal?
The client portal is intended to give clients access to information you make available to them. Check the client view as part of project setup and explain how status updates will be used. Avoid assuming that internal shorthand is meaningful to a client. A visible task should communicate the outcome or decision in language they recognise.
What belongs in the launch handover?
Include the delivered scope, account ownership, relevant operating instructions, known limitations and the support route. Record where the client can find their deliverables and who handles future changes. Keep sensitive access details in an appropriate secure process. A handover is complete when another responsible person can operate the site, not merely when a folder has been shared.
Does website monitoring replace manual quality assurance?
No. Availability checks can identify a site that is not responding, but they do not establish that every form, checkout, navigation path or piece of content works correctly. Test the user journeys that matter to the business before and after launch. Treat monitoring as one part of ongoing service alongside investigation, maintenance and communication.
How should a maintenance ticket be written?
State what happened, the affected URL or feature, when it began and the business impact. Include reproduction steps and a screenshot when useful, without exposing private customer details. Assign an owner and clarify the next update. A precise ticket reduces back-and-forth and helps the team distinguish a new feature request from a defect or an availability incident.
Can we keep design tools and use Agency Pilot for delivery?
Yes, evaluate Agency Pilot as the operational home for the client and project while retaining the specialist tools your designers and developers need. Link or document the relevant deliverable through the supported workflow. Do not assume a native integration or automatic file synchronisation without checking it. The aim is clear responsibility and context across the tools you choose.
How should several client stakeholders provide feedback?
Ask the client to name one person who consolidates comments and resolves conflicting preferences. Let subject specialists review their areas, but avoid presenting contradictory requests as a single approved instruction. Record the decision and the version affected. This matters most when brand, sales and operations teams each have a different reason for wanting a page changed.
When should a website project become ongoing support?
Agree the transition before launch, including any completion criteria, post-launch correction period and maintenance start date. The first support request should not be the moment either side discovers the boundaries. Create the ongoing responsibilities from that agreement and explain the reporting route. Keep unfinished build tasks distinguishable from new retainer work so billing and expectations remain clear.
How can a small design team cover an absence?
Keep current status, next actions, dependencies and client decisions in the project record. Name someone who can respond when the usual project lead is away. A colleague should be able to identify the approved version and outstanding request without reading every historical message. Review one active project together to find gaps before an absence makes them urgent.
What should we test during a software trial?
Run a compact example that includes onboarding, a design review, a client decision, a launch checklist and a support request. Check how your team and client would find the relevant information at each stage. Note any steps still handled in specialist tools. A complete workflow gives a more realistic evaluation than a beautifully populated board that nobody has used.