Evidence you can use to make a decision

A useful agency software case study connects a specific operating problem with a documented change in how the team works. It should explain who used the software, what they changed, and which measurements support the result. A screenshot of a rising chart is only one part of that story. The reader also needs to understand the reporting period, the starting conditions, and the work that happened alongside the software rollout.

This hub is designed to help you evaluate that evidence before making a buying decision. Customer-approved outcome stories will be added when the underlying measurements and publication permissions are available. Until then, use the evaluation workflows here to plan your own assessment. They describe tasks to test in Agency Pilot and evidence to collect; they do not represent completed customer projects or promised improvements.

Write down the service mix, client count, team roles, and location complexity before comparing an example with your own agency. A solo consultant delivering a monthly local SEO service faces different coordination problems from a team managing paid advertising, website projects, and several client stakeholders. A workflow that looks efficient in one setting may need additional approvals or specialist tools in another.

Include the previous process as part of the context. Identify where requests arrived, where task ownership lived, and how reports reached clients. Record which tools remain in use during the evaluation. This makes the eventual account of the change more informative: a reader can see which problem the platform addressed, which dependencies stayed in place, and which part of the workflow still required manual work.

Choose a representative client and document the access your team needs to begin delivery. List the relevant accounts, the owner who can grant access, and the person responsible for checking the result. Use the onboarding workflow to request the supported connections, then confirm what the team can actually see or do. Sending a request is a useful milestone, but it is different from having the permissions needed to complete the work.

For an onboarding case study, retain the request date, completion date, follow-up count, and a short explanation of delays. Distinguish time spent by the agency from time waiting for a client administrator. Include unsuccessful or incomplete connections in the review instead of removing them from the story. This approach gives another agency a realistic view of the effort, dependencies, and communication involved in starting an account.

Select the location, keywords, geographic coverage, and reporting cadence before collecting a baseline. Record the scan settings so the next observation uses a comparable method. Have the account manager explain what the measurements mean and what they do not establish. A ranking observation describes visibility under the chosen settings; it does not by itself demonstrate additional customers, revenue, or a causal effect from a particular task.

Follow one reporting cycle through research, interpretation, client communication, and the next action. Save the report configuration and note which findings resulted in an actual delivery decision. A useful story can show how the team organized this process without claiming that the software caused a ranking improvement. When results change, describe other relevant activity and uncertainty, including website changes, seasonality, competition, and differences in the measurement setup.

Pick a prospect whose requirements resemble your normal client work. Document the proposed scope, relevant stakeholders, and the details the delivery team will need after acceptance. Follow those details through the available proposal and client-management workflow. Check whether the person starting the work can understand the promise made during the sale without reconstructing it from several conversations.

Useful evidence includes whether required information was present, how ownership was assigned, which questions needed clarification, and what work remained outside the platform. Avoid defining success only as a signed proposal: sales outcomes depend on the offer, relationship, pricing, and many other factors. The workflow assessment should focus on whether the agreed scope and responsibilities become a clear starting point for delivery. Record any duplicate entry that still occurs.

Prepare a specific task for the client to complete, such as finding a recent report or reviewing the information shared for their account. Confirm the intended permissions before inviting a participant. Let the client attempt the task without a staff member narrating every click, then ask which labels or steps were unclear. Keep the exercise narrow enough that the feedback is actionable.

Record whether the task was completed, which help was needed, and what the client expected to find elsewhere. Do not equate a login with successful adoption. An agency can also track whether the portal becomes part of a regular review meeting or reporting process. A publishable account should describe how the client was introduced to the workflow and which habits or communication practices supported its continued use.

Choose a small set of measures before the pilot begins. For reporting, separate data collection, interpretation, quality review, and distribution. For onboarding, separate active effort from elapsed waiting time. For delivery, define what counts as a completed task and how rework is recorded. Consistent definitions make the result understandable and reduce the temptation to compare different activities under the same label.

Use a worksheet or existing time records to capture observations. Note missing entries and unusual workloads rather than filling gaps with guesses. If the agency changes its service package during the pilot, explain how that affects the comparison. An honest result may show improvement in one step and additional effort in another. Those details help a prospective customer judge the tradeoff for their own team.

Opening a dashboard, sending a report, and completing an onboarding request are product or process events. Renewals, qualified leads, revenue, and margin are business outcomes. They can be related, but the relationship needs evidence. A case study should label the type of result being reported and avoid implying that an observed business change was produced solely by adopting a platform.

If an agency chooses to discuss revenue or retention, define the measurement period and the population included. Explain other changes that could have influenced the result, such as new services, different prices, staff changes, or an advertising campaign. When causal evidence is unavailable, describe the sequence of events accurately. A measured operational improvement is useful in its own right and does not need an unsupported revenue claim to become meaningful.

Include the time spent configuring the workflow, introducing staff, connecting accounts, and checking data. Keep those initial activities separate from recurring work after the team has learned the process. This distinction helps a reader understand whether a result reflects a mature routine or an early pilot. It also makes a purchasing conversation more realistic by accounting for the work required to get started.

Check the current pricing page for plan eligibility, capacity, optional add-ons, and credit-consuming actions. Record the costs shown for the research actually performed. If another subscription remains necessary, include it in the evaluation rather than implying it was replaced. A useful cost comparison describes a specific workload and billing interval, with clear assumptions about the services the agency intends to deliver.

Keep the workflow description, dated observations, measurement definitions, and approved screenshots together. A reviewer should be able to follow how each published statement was derived. For calculated measures, retain the underlying entries and the calculation. For qualitative findings, record the question asked and the participant’s actual response. Summaries are useful, but they should not transform mixed feedback into an unqualified success claim.

Remove unnecessary client information from material prepared for publication. Review account names, email addresses, private conversations, identifiers, and financial details before sharing a screenshot. Obtain approval for any customer identity, logo, quote, or outcome statement that will appear in the public story. A small, well-supported evidence packet is more useful than a large collection of images whose context cannot be checked.

At the end of the evaluation, compare the observed workflow with the requirements recorded at the start. Identify what worked, what needs configuration or training, and what requires another product or process. Assign an owner to unresolved questions and decide which ones must be answered before wider adoption. A product demonstration can show possibilities; the pilot should establish what your team can repeat in normal delivery.

Consider a limited rollout before moving every account. Choose the next group based on service similarity and the team’s ability to support the change. Keep the previous records available according to your own retention process, and check that important information remains accessible. The strongest case-study conclusion is a specific decision supported by the evidence, including the boundaries within which the agency expects the workflow to work.

If your agency uses Agency Pilot and would like to discuss a case study, contact the team with a short description of the workflow you evaluated. Include the service context, the period covered, and the kinds of evidence available. You do not need to send private client records in an initial inquiry. The first conversation can establish the topic and the information needed to assess it.

Publication should follow review of the factual statements and the customer’s approval of the material attributed to them. Any incentive connected to participation should be disclosed where relevant. Until that review is complete, an example remains an evaluation or draft rather than a verified customer outcome. This standard gives future readers a clearer basis for comparing the experience with the needs of their own agency.