Well Drilling Case Study Template: Contractor Guide

A good case study gives a future buyer a reason to believe your company can handle a similar job. A bad one is a polished paragraph that says the work went well.

For a well drilling or pump company, the difference is evidence. The story needs the job context, site conditions, field record, judgment, measured outcome, and customer permission in one place.

This template gives you that structure. It is written for US contractors who need a sales asset they can use in a proposal, follow-up, service page, referral conversation, or qualification call.

What should a well drilling case study prove?

A well drilling case study should prove that the contractor understood a real job, made decisions for the conditions, completed defined work, measured the result, and can show where the proof came from. It should not promise that another site will produce the same result.

Generic case-study templates usually move from challenge to solution to results, often adding a quote and next step. That sequence is useful, but it is too thin for groundwater work, as the structures described by Smartsheet and Zoomforth show. A buyer may need to know what was encountered, what was installed, how the system was tested, what changed from the initial plan, and whether the result was recorded by the contractor, a laboratory, a regulator, or the customer.

The central question is not, “Can we make this project sound impressive?” It is:

Can a similar buyer understand what happened, why it happened, and what evidence supports the claim?

That question changes what you collect before writing. You are not gathering adjectives. You are gathering a chain of evidence.

A case study is a sales asset only after its proof survives a skeptical reader.

The well log is evidence, not the story.

A well log or construction report is built for a regulatory, technical, or ownership purpose. A case study is built for a buyer who needs to assess judgment and fit. The case study can use the record, but it must translate the record into a decision a buyer can understand.

The difference between a record and a case study

Item	Record or form	Buyer-facing case study
Main job	Preserve required project facts	Explain why the work matters to a similar buyer
Typical reader	Regulator, owner, inspector, future service provider	Property owner, developer, farm operator, facility manager, or referral partner
Detail style	Field terminology and required fields	Plain explanation with technical detail where it changes the decision
Evidence	Measurements, signatures, test results, construction details	Selected evidence tied to a problem, decision, and outcome
Risk	Missing required information or inaccurate filing	Overclaiming, exposing confidential information, or making a result sound universal
Best use	Compliance, handoff, maintenance, future reference	Proposal support, trust, qualification, and sales conversations

The two assets should agree. If the case study says one thing and the well record says another, stop and resolve the conflict before publishing.

Which project should you choose for the case study?

Choose a project that a target buyer can recognize, that has enough evidence to support the story, and that your customer has approved for publication. The biggest job is not automatically the best job.

A useful project usually has at least one of these qualities:

• It represents a service you want more of.
• It shows a difficult decision that your team can explain clearly.
• It includes a measurable outcome rather than only a finished photo.
• It resembles the territory, customer type, geology, access problem, or system issue you want to pursue.
• It has complete records and a customer who is willing to confirm the story.
• It demonstrates disciplined handling of a change, constraint, or unexpected condition.

An ordinary project can be more persuasive than a dramatic one if it matches the buyer's situation. A rural replacement pump with a clear diagnosis, documented test, and clean handoff may be more useful to a pump customer than an unusual deep drilling project that has no comparable context.

Use the project-fit score

Score each candidate from 0 to 2. A score of 2 means the condition is strong, 1 means partial, and 0 means absent. This is a Brictale editorial tool, not an industry standard.

Selection question	0	1	2
Does it match a service you want more of?	No	Somewhat	Direct match
Can you explain the buyer's original problem?	Unknown	Partial notes	Clear and approved
Do you have field and completion evidence?	Missing	Some records	Record set is usable
Is the result measurable?	No measure	Qualitative only	Defined measure and date
Can you explain a real decision or constraint?	No	Minor	Material and clear
Is customer permission realistic?	No	Unclear	Confirmed or in progress
Can you protect confidential details?	No	Needs redaction	Yes
Does the story fit your target territory or customer type?	No	Adjacent	Strong fit

Use the highest-scoring project only after checking the release risks. A high score with no permission is still a no-go.

When the most impressive project is the wrong project

Do not choose a project simply because it has a large depth, a difficult formation, a high invoice, or an unusual piece of equipment. Those details may interest another contractor, but they do not automatically help a buyer decide.

Ask what the project teaches. If the answer is only “we did a big job,” the story needs a sharper angle. A useful angle might be:

• How the crew handled restricted access without hiding the schedule impact.
• How a pump replacement was selected after diagnosis instead of guessing from a symptom.
• How the scope changed after field conditions differed from the initial assumption.
• How the team documented yield, drawdown, recovery, or return-to-service performance.
• How the contractor protected the buyer from a decision that could not be justified by the available evidence.

Those are decisions. Decisions create a case study.

What records should you collect before writing?

Collect the original scope, field notes, required well or pump records, test data, photos, change documentation, and customer approval before drafting the narrative. Writing first and looking for proof later is how unsupported claims enter a case study.

The exact record set depends on the service and jurisdiction. State rules are not interchangeable. Ohio's statute, for example, names formations, depths where water is encountered, static water level, pumping tests, construction details, pumping equipment, owner and location, and the constructor's signature as parts of a well construction log. It also prohibits false statements in a required log or sealing report. Ohio Revised Code Section 1521.05.

Washington's rule similarly requires a complete report based on field notes and lists drilling method, formations, water-bearing zones, casing, tested capacity, drawdown, recovery, static water level, and signatures. WAC 173-160-141.

Washington State's rule gives the evidence chain a useful standard: “The report must be an accurate summation of the data collected in the field taken from field notes written as the well was constructed.” WAC 173-160-141. This is a writing principle for the template, not a claim that Washington's rule governs every US contractor.

Treat these public requirements as prompts for completeness, not as a 50-state checklist. Minnesota's health department, for example, describes a Well and Boring Record that covers construction details, depth to groundwater, geology, well components, and pump information, while also giving Minnesota-specific testing instructions. Minnesota Department of Health.

The buyer's side matters too. The National Ground Water Association tells prospective well owners to ask about written contracts, itemized costs, well logs, yield testing, disinfection, equipment, and the finished well record. NGWA's contractor handout. Those questions are useful prompts for a case study because they show what a future buyer may want to verify.

The collection step should answer four questions:

1. What did we know before work started?
2. What did we observe while doing the work?
3. What did we install, change, or test?
4. What can we prove after completion?

The prewriting evidence packet

Create one folder or project record with these sections. Mark each item available, partial, not applicable, or restricted.

Evidence group	Collect	Why it matters in the case study
Identity	Project type, service, general location, customer type, intended use, date range	Establishes whether the story is relevant to the next buyer
Original scope	Contract, proposal, work order, specifications, inclusions, exclusions	Defines what the company agreed to do
Site and conditions	Access, surface conditions, known geology, existing system, utilities, constraints	Explains why the work required judgment
Field record	Daily notes, drilling notes, formation observations, water encounters, photos, crew observations	Anchors the story in what was actually observed
Construction or repair	Depth, casing, screen, seals, pump, controls, pressure system, wiring, repair parts, sequence	Shows what changed and how the work was executed
Testing	Yield, drawdown, recovery, pressure, flow, electrical, water-quality, or return-to-service tests as relevant	Defines the result and its conditions
Commercial record	Change orders, schedule, invoice, cost categories, warranty, callback, closeout	Shows scope and business outcome without inventing savings
Customer proof	Quote request, approval, named attribution, photos, logo, location permission	Makes the published asset lawful and credible
Limits	Redactions, confidential figures, unverified claims, unresolved issues	Stops the story from saying more than the evidence supports

North Carolina's public residential well construction record shows why identity fields belong near the start of the packet. The form includes intended use, date drilled, location, parcel information, and coordinates. North Carolina DEQ GW-1a. A buyer does not need every form field in the public story, but the writer needs enough project identity to keep the story anchored to a real job.

What to do when records are missing

Missing records do not give you permission to fill the gap with a plausible number. Use one of four labels:

• Documented: the original record exists and supports the statement.
• Confirmed: a named person confirms the fact, but the original record is not available.
• Estimated: the number was calculated or approximated, with the method shown.
• Not available: the fact matters but cannot be verified, so it is omitted or described as unknown.

If a result is important and the record is missing, rewrite the claim. “The well produced 18 gallons per minute” is not supported by a memory or a photo of a gauge. “The team completed the installation and provided the available completion records” may be supportable if the handoff record confirms it.

A case study earns trust when every important result has a source, baseline, date, and owner.

How do you turn field records into a buyer-readable story?

Use the Groundwater Proof Stack. It keeps technical evidence and business meaning connected without turning a case study into either a dry report or a sales exaggeration.

The Groundwater Proof Stack

Layer	The writer asks	The buyer should learn	Evidence to attach or cite
Context	What kind of job was this?	Whether the project resembles the buyer's need	Approved project summary, service category, general location, intended use
Field record	What was observed and installed?	Whether the contractor worked from facts	Well log, field notes, construction record, pump details, photos, test sheet
Judgment	Why did the team choose this path?	Whether the contractor can reason through constraints	Scope, alternatives, daily notes, change order, engineer or owner direction
Outcome	What changed and how was it measured?	What the buyer can reasonably expect to evaluate	Before-and-after definition, test conditions, dates, completion record, invoice or schedule
Proof and limits	Who confirms the claim and what does it not prove?	Whether the story is honest and transferable	Approval, quote, attribution, source note, limitation statement

Every paragraph in the final case study should belong to at least one layer. If a sentence belongs to none, cut it or explain why it is needed.

Context: make the project recognizable

The context section should be short. It is not a company biography. It tells the reader enough to decide whether to continue.

Use:

• Contractor service: new well, replacement well, pump installation, pump repair, well rehabilitation, pressure system, inspection, testing, or another defined service.
• Customer type: residential, agricultural, commercial, municipal, industrial, or another approved category.
• General geography: county, region, or state only if the customer approves it and the detail does not expose private information.
• Intended use: water supply, irrigation, livestock, process water, or another accurate description.
• Starting condition: new site, failed pump, low pressure, poor yield, water-quality concern, incomplete record, access constraint, or a different documented problem.
• Success definition: completed installation, target test, restored service, documented handoff, reduced downtime, resolved scope issue, or another measurable objective.

Avoid a vague opening such as “The customer needed a reliable water solution.” Name the decision. “The operator needed a replacement pump for an existing well that was losing pressure during normal use” gives the reader something to evaluate.

Field record: select facts that change the decision

The field record is not a dump of every note. Choose the details that explain why a method or component made sense.

For a drilling project, that might include formation changes, depth of water encounters, static level, casing, screen, seal, filter pack, drilling method, test capacity, drawdown, recovery, and wellhead details when they are relevant and approved. Washington's rule lists these categories in its reporting requirements. WAC 173-160-141.

For a pump job, the relevant record might include the reported symptom, diagnosis, motor or pump condition, pressure readings, control issue, replacement decision, electrical checks, flow or pressure test, and return-to-service condition. Do not add a drilling field simply to make a pump repair story sound technical.

Translate each technical fact into a buyer question:

Technical fact	Buyer question it answers
Formation or water-bearing zone	What did the crew learn about the site?
Casing and screen details	How was the completed well configured?
Static level, yield, drawdown, recovery	How was performance tested and described?
Pump model or type	What equipment was selected or replaced?
Pressure reading or flow test	How was the fault or outcome evaluated?
Access or site constraint	What made the job difficult, and how did the team plan around it?
Change order	What changed, who approved it, and why?
Completion record	What was handed off and when?

Judgment: show the decision, not just the deliverable

A case study becomes persuasive when it explains a choice. “We installed a pump” is a deliverable. “The original pump could not maintain the required pressure, so the contractor tested the system, documented the failure point, and proposed a replacement that matched the existing well and electrical conditions” is a decision path.

Use this sequence for each major decision:

1. Condition: What was known or observed?
2. Risk: What could go wrong if the obvious path was chosen?
3. Options: What alternatives were considered or ruled out?
4. Choice: What did the contractor recommend or perform?
5. Trade-off: What cost, time, access, or uncertainty came with that choice?
6. Check: What test, record, or approval confirmed the next step?

Do not invent alternatives that never existed. If the crew did not compare two methods, say that the selected method was specified by the approved scope or directed by the owner. If the decision was made under a state requirement, identify the requirement and link to the governing source rather than claiming the rule applies nationwide.

Outcome: define the before and after

“Better water” is not a result. “The system was tested at [value] for [duration] on [date], with [measurement] recorded under [conditions]” is a result format. The blanks must be filled only with data you can support.

Possible outcome categories include:

• Technical: tested capacity, pressure, drawdown, recovery, electrical reading, flow, water-quality result, or other job-specific measure.
• Delivery: completion date, approved schedule change, number of mobilizations, handoff status, or documentation delivered.
• Scope: work completed, change order accepted, included and excluded items, or difference between planned and actual work.
• Operating: service restored, pressure condition addressed, pump cycle issue corrected, or a documented period without a repeat call.
• Commercial: approved cost category, documented change, avoided rework, or invoice status, only when the customer permits publication and the records support the claim.
• Customer voice: a direct quote that describes the customer's experience, with attribution and permission.

Do not call an estimate a saving. Do not call a completed test a guarantee. Do not turn a one-day reading into a permanent performance promise.

CDC guidance recommends annual testing for total coliform bacteria, nitrates, total dissolved solids, and pH for private well water, along with local guidance and state-certified laboratories. CDC Guidelines for Testing Well Water. EPA guidance also says testing decisions depend on local conditions and may be appropriate after a repair or replacement or when water quality changes. US EPA. For a contractor case study, the point is to label what was tested, when, by whom, and for what purpose. Do not present one water test as proof of every aspect of system performance.

How should you explain the project challenge?

Write the challenge as a starting condition with a consequence, not as a dramatic story. A buyer should understand what was wrong, what mattered, and what the contractor had to protect.

Use this fill-in structure:

[Customer type] needed [service or outcome] at [general location or site type]. Before work, [documented condition] created [operational, schedule, quality, or scope problem]. The project was constrained by [access, geology, existing system, permit, budget, timing, or other documented factor]. Success meant [specific completion or measurement].

Weak and strong challenge statements

Weak	Stronger
The customer had a difficult well.	The existing pump lost pressure during normal demand, and the owner needed a documented diagnosis before approving replacement work.
We were hired for a challenging drilling project.	The site required a new water-supply well, but the available access route limited rig positioning and the approved scope required the contractor to document construction and testing.
The system was old and unreliable.	The pressure system produced intermittent service, and the service record showed repeated troubleshooting without a confirmed failure point.
The customer wanted better water.	The customer reported a change in water appearance and requested inspection and testing before deciding whether repair or replacement was appropriate.

The stronger statements use conditions that can be checked. They do not assume the contractor caused the starting problem or that the customer had no other option.

Do not hide the hard part

A case study that removes every complication sounds less credible. Include the constraint that changed the plan, if the customer has approved it and the statement is accurate.

Examples:

• Access required a different staging sequence.
• A field condition changed the expected depth or method.
• The original equipment was not compatible with the existing system.
• The project required an additional test before the owner could approve the next stage.
• A scope change affected price or schedule and was documented before the work proceeded.

The point is not to make the contractor look heroic. The point is to show how the contractor handled the work when the first plan met reality.

How should you explain drilling, pump, or repair decisions?

Explain decisions in the order a buyer would make them: what was known, what was uncertain, what options existed, why one option fit, and how the result was checked.

The decision record

Use a table like this for the two or three decisions that matter most.

Decision	Information available	Options considered	Selected path	Trade-off or limitation	Confirmation
[Decision]	[Field fact or contract requirement]	[Actual alternatives, if any]	[Work performed]	[Time, cost, access, uncertainty]	[Test, record, approval]

Do not fill the table with technical detail that never affected the work. A case study is not stronger because it includes every part number. Include the part number when it helps the reader compare a similar system, when it is approved, and when it is still accurate.

How to write about geology without pretending certainty

Use the language of observation and record:

• “The field notes recorded...”
• “The completion record listed...”
• “The crew encountered...”
• “The test sheet showed...”
• “The approved scope called for...”
• “The owner selected...”

Avoid:

• “We knew exactly what was underground.”
• “This method always produces...”
• “The site guaranteed...”
• “The contractor eliminated all risk.”

Groundwater work involves conditions that may vary by site. A case study should show how the contractor managed uncertainty, not pretend uncertainty did not exist.

How to write about pump selection or repair

The buyer needs the path from symptom to decision. Use:

1. Reported symptom and operating context.
2. Inspection or diagnostic step.
3. Confirmed or suspected failure point.
4. Repair, replacement, or monitoring options.
5. Selected work and reason.
6. Test or operating check after work.
7. Follow-up condition and limits.

If you do not have a post-work test, say so. “The pump was replaced and the system returned to service” is different from “The replacement permanently solved the system.” The first may be documented by the work order. The second needs a longer, defined observation period and evidence.

Do not use a case study to give homeowner instructions

The audience for this page is the contractor decision maker. A finished case study may be read by homeowners, developers, or facility operators, but the template should stay focused on how the contractor documents and presents work.

Do not turn the project story into generic advice about drinking water, DIY pump repair, or diagnosing a private well. Link to the relevant public health or regulatory source when the story needs context, then return to the contractor's evidence and decisions.

What is the copy-ready well drilling case study template?

Copy the structure below into your project folder, then replace every bracketed field with a documented fact, an approved quote, or an explicit limitation. Delete prompts that do not apply. Do not leave generic claims in place.

Title

How [contractor or service type] handled [specific problem or decision] for [approved customer type] in [approved region]

Alternative title patterns:

• [Service]: resolving [documented problem] under [constraint]
• From [starting condition] to [measured outcome]: a [service] project
• How [customer type] received [defined service outcome] after [problem]

Do not use a result in the title unless it appears in the body with a source, date, and conditions.

Snapshot

Field	Fill in
Customer	[Name only if approved; otherwise customer type]
Service	[New well, pump repair, pump replacement, rehabilitation, testing, inspection, or other]
General location	[Region, county, or state if approved]
Starting problem	[One sentence with a documented condition]
Constraint	[One material constraint]
Work performed	[One sentence]
Main measured outcome	[Metric, test, or completion result with date]
Evidence owner	[Contractor record, lab, regulator, customer, or other]
Approval status	[Pending, approved, approved with redactions]

Customer and project context

[Customer type] operates [approved business or property context] in [approved general area]. The project involved [service] for [intended use or operating need]. The original scope included [scope]. It excluded [exclusions, if important].

The customer approved publication of [name, region, photos, quote, project data, or anonymized description] on [date or approval reference].

The starting problem

Before work began, [documented symptom, condition, or requirement]. The condition mattered because [operational, schedule, quality, safety, or commercial consequence]. The available information at the start was [records, inspection, owner report, or test]. The project would be considered complete when [defined success condition].

The site and operating constraints

The work was performed under [access, terrain, existing equipment, geology, utility, permit, schedule, weather, budget, or customer constraint]. The team could not assume [uncertain condition]. The constraint changed [method, sequence, equipment, schedule, or scope] by [documented change].

Use only constraints that affected the work. A list of every inconvenience makes the important one harder to see.

The evidence collected

The project file included [well log or construction report], [field notes], [photos], [equipment records], [test results], [change documentation], and [completion or handoff record]. The following claims in this case study are based on those records: [list]. The following information was withheld or anonymized: [list].

For a well construction story, compare the packet against the applicable state requirements. Ohio, Washington, Minnesota, and other states differ in their forms, deadlines, signatures, and testing obligations. Do not publish a universal compliance statement from one state's form.

The decision path

The team first [inspection, planning, or record review]. It then considered [actual options or approved scope]. The selected path was [work performed] because [documented reason]. The trade-off was [time, cost, access, uncertainty, or other]. Before moving to the next stage, the team checked [test, measurement, approval, or record].

Repeat this section for the two or three decisions that changed the outcome. If there was no meaningful choice, describe the specified work and say who specified it.

The work performed

The contractor performed [scope] between [dates]. The work included [key tasks]. The project changed from the initial plan in these documented ways: [changes]. The customer or authorized representative approved [change, if applicable] on [date or record].

Keep “performed” separate from “recommended.” A recommendation is not a completed installation. A test request is not a test result.

The measured outcome

Use one row per result.

Measure	Before	After	Date or period	Method or source	Limitation
[Metric]	[Baseline or not available]	[Result]	[Date or period]	[Test, record, or system]	[What it does not prove]

At completion, [record or test] showed [result] under [conditions]. The result should be read as [defined outcome], not as a guarantee of [excluded or unmeasured outcome].

For water-quality information, identify the laboratory and test scope when approved. CDC says to use a state-certified laboratory and to consider local guidance for what to test. CDC. For a repair or replacement, identify whether the result is a same-day return-to-service check or a longer operating observation.

Customer quote

“[Exact approved quote about the customer's experience].”

- [Name, title, customer or company, if approved]

If you do not have an exact approved quote, remove this section. Do not write a quote for the customer and ask them to approve it as if they said it. You can ask questions and accurately transcribe the answer, but the final words and attribution need approval.

What the project teaches

For a similar [customer type or service], the useful lesson is [decision or preparation point]. The project does not establish [unmeasured or non-transferable claim]. A contractor evaluating a similar job should confirm [site, record, test, or scope question] before promising [outcome].

This is where the case study becomes useful to the next buyer without turning one project into a guarantee.

Next step

If your project has a similar [problem, service, or constraint], the next step is [site conversation, record review, inspection, or quote process]. Bring [specific information] so the contractor can assess fit before giving a recommendation.

The website template owns the commercial CTA. On a Brictale-supported page, the natural path is the free territory audit for a contractor that wants to assess its current proof, service coverage, and qualified-call opportunities. Do not add a second offer or a made-up result.

How should you write results without overclaiming?

Write results as measured observations with a defined time, method, and limit. A result is not automatically a cause, a guarantee, or a typical outcome.

The FTC says endorsements and testimonials must be truthful and not misleading. Its guidance also warns that advertisers can face responsibility for claims made through testimonials, and its consumer reviews and testimonials Q&A notes that agencies can be liable for creating fake or false testimonials. FTC Advertisement Endorsements and FTC Consumer Reviews and Testimonials Rule Q&A.

That does not mean a contractor cannot publish a customer story. It means the story needs a clear basis.

Use the claim ladder

Claim level	Example	What you need
Work completed	“The contractor installed the specified pump.”	Work order, completion record, or invoice
Test observed	“The test sheet recorded [value] at [time] under [conditions].”	Original test record and method
Customer experience	“The owner said service returned after the repair.”	Approved quote or documented customer confirmation
Operational period	“The system operated without a reported callback for [defined period].”	Service or callback records covering that period
Business impact	“The project reduced [cost or downtime] by [amount].”	Baseline, calculation, records, and customer permission
Causal claim	“This decision caused the company to gain [result].”	Strong attribution evidence, not just timing

Use the lowest claim level that answers the buyer's question honestly. If you have a test and a customer quote, you do not need a grand causal claim.

Separate facts, estimates, and interpretation

Use labels in your draft:

• Fact: “The completion record lists a depth of [value].”
• Observation: “The field notes show that access changed the staging sequence.”
• Estimate: “The schedule impact is estimated at [value] using [method].”
• Customer statement: “The owner said [approved quote].”
• Interpretation: “This suggests the staging plan reduced the need for a second mobilization.”
• Recommendation: “For a similar site, confirm access before finalizing the sequence.”

These labels make review easier and keep a writer from turning an inference into a fact. If the published page removes the labels, preserve the distinctions through wording.

Avoid the result phrases that create risk

Do not use these without unusually strong support:

• “Guaranteed yield.”
• “Permanent fix.”
• “Zero risk.”
• “Best possible result.”
• “Solved every problem.”
• “Always works.”
• “Typical savings.”
• “The same result for your property.”

Use measured alternatives:

• “The documented test recorded...”
• “The system returned to service at the completion check...”
• “The owner reported...”
• “During the recorded period...”
• “The approved scope included...”
• “The result is specific to this site and test condition.”

A limitation stated clearly is stronger than a guarantee you cannot support.

How should you handle customer names, photos, and quotes?

Get written approval before publishing any identifying detail, customer quote, project photo, logo, location, result, or cost information. If approval is not available, anonymize the story or do not publish it.

Your permission record should state:

• Customer or company name approved for use.
• General location or exact location approved for use.
• Customer type and project description approved for use.
• Photos, video, logos, equipment images, and site images approved for use.
• Metrics, prices, schedule, test values, and results approved for use.
• Quote text, speaker name, job title, and attribution approved for use.
• Channels approved: proposal, website, social post, email, sales deck, or other.
• Whether the customer may review factual changes before publication.
• Whether the approval can be withdrawn or updated.

Do not treat a positive conversation as publication permission. A customer may be happy with the work and still not want the location, business name, or equipment details online.

The permission workflow

1. Ask before drafting the public version when possible.
2. Explain what you want to publish and where it will appear.
3. Ask factual questions about the starting problem, work, and outcome.
4. Draft from records, not from the customer's preferred story alone.
5. Send the draft for factual review and permission confirmation.
6. Resolve differences between the draft, project records, and customer feedback.
7. Save the approved version and permission record with the project file.
8. Review the page before reuse in another channel.

If the customer wants a claim removed, remove it unless another lawful and documented reason requires correction. A case study is a sales asset, not a dispute forum.

Anonymous case studies can still work

An anonymous case study can be useful when it preserves the details a similar buyer needs:

A commercial water user in [state or region] needed [service] after [documented condition]. The site had [approved constraint]. The contractor performed [scope], recorded [test], and delivered [handoff].

Remove exact addresses, parcel numbers, names, identifiable photos, unique equipment combinations, and timing details that could identify the customer. Do not call an anonymous story “customer [name].” Say that the customer is anonymized.

An anonymous story is weaker when it hides every meaningful fact. If the only published detail is “a customer had a problem and we fixed it,” do not call it a case study. Publish a general service explanation instead.

How do you make the case study useful in proposals and search?

Create one complete source version, then adapt it to the context where the buyer will read it. The proposal version, website version, follow-up version, and sales-call version should share the same approved facts.

The four useful versions

Version	Length and job	Keep	Remove or shorten
Proposal proof block	Half page to one page	Similarity, challenge, decision, result, quote, next step	Background that does not affect the buyer's decision
Website case study	Full story	Evidence chain, photos, decision table, test conditions, limits	Internal notes and confidential commercial details
Follow-up email	Three to six short paragraphs	One similar problem, one decision, one measured result, one link	Full technical record
Sales-call reference	One screen or printed sheet	Snapshot, proof sources, objections, questions to ask	Marketing language and long narrative

The existing well contractor proposal cover letter template can help frame the case study as proposal evidence, while the well drilling project closeout checklist can help confirm which completion, handoff, and record items should already exist. These pages solve different jobs. Use them together rather than turning the case study into a second proposal or closeout checklist.

Use a service page as the destination, not the whole story

A case study can support a service page, but it should not replace the service page. The reader still needs to know what the contractor does, where it serves, what the process includes, and how to start.

Before linking a case study to a service page, check that the service page clearly states the service, customer fit, territory, proof, and next action. Brictale's well drilling service page coverage benchmark gives a way to score that coverage. The case study then supplies specific proof for one part of the page.

Use the case study in a qualified-call process

The goal is not to make every reader call. The goal is to help the right buyer recognize a similar job and give your team enough information to decide whether the conversation is worth dispatching.

Use a short intake around the case study:

• What service is needed?
• Where is the job?
• What is happening now?
• What existing records are available?
• What timing or operating constraint matters?
• Is the caller the owner or authorized decision maker?
• What is the requested next step: records review, inspection, quote, or emergency response?

Do not imply that a published case study means the contractor can accept every similar job. Capacity, licensing, geography, equipment, and scheduling still matter.

The best project to publish is the one a target buyer can recognize and verify.

When should you not publish a well drilling case study?

Do not publish when the story cannot be verified, the customer has not approved it, the result is too site-specific to explain, or the page would create a promise your team cannot defend.

Pause or reject the draft when:

• The project file has no reliable starting condition.
• The result depends on a number you cannot trace to a record.
• The customer name or location is being used without clear permission.
• The customer is represented as saying words they did not say.
• The story hides a material change order, failed test, unresolved callback, or limitation.
• A state-specific requirement is presented as a national rule.
• The project has a confidentiality agreement that covers the relevant details.
• The published result would invite a buyer to infer a guarantee.
• The only unique feature is a large invoice or a dramatic adjective.
• The case study would be more useful as a service explanation, checklist, or public technical record.

The right alternative when a case study is not ready

Use the evidence you do have honestly:

Situation	Better asset
Work is complete but no customer permission	Private internal reference or anonymized draft
Customer approved a quote but records are incomplete	Short testimonial with narrow claim, not a full technical case study
Records are complete but there is no distinctive decision	Project closeout summary or service-page proof block
The project is still open	Project log, proposal support, or internal lessons document
The work is confidential	Generalized process explanation with no identifying details
The result is not yet measured	Completion update that states the measurement is pending
The contractor wants more qualified calls	Territory and service coverage audit before producing more content

Do not force every completed job into a public story. A smaller library of accurate, relevant case studies is more useful than a page for every invoice.

How do you review the finished case study before release?

Use a two-pass review. The first pass checks whether the story is true and approved. The second checks whether a buyer can understand it quickly.

Pass one: evidence and permission

• The customer or customer type is described accurately.
• The service and intended use are correct.
• The starting problem is supported by a work order, note, inspection, or customer confirmation.
• The site or operating constraint is documented.
• Every technical result has a source, date, and conditions.
• Any estimate includes its method and label.
• Work performed is separate from recommended work.
• Change orders and major scope changes are represented accurately.
• Test results name the method, party, or record where relevant.
• State and local requirements are not generalized beyond their jurisdiction.
• Customer name, quote, image, result, location, and logo permissions are saved.
• Redactions do not make the remaining claim misleading.
• The story does not imply that one site proves a universal result.

Pass two: buyer usefulness

• The first paragraph tells the reader what service and problem the story covers.
• A similar buyer can identify the relevant constraint.
• The contractor explains at least one meaningful decision.
• The result is easy to find and not buried in adjectives.
• The evidence source is understandable to a non-specialist buyer.
• The page states what the result does not prove.
• The next step is appropriate to the service and stage of the buyer.
• The page links to one relevant service or supporting resource.
• The language is specific to well drilling or pump work, not generic agency copy.
• The page does not give homeowner DIY instructions.

The 60-second reviewer test

Give the draft to someone who did not work on the project. Ask them to answer these questions without help:

1. What did the contractor do?
2. What was wrong or at stake?
3. What was difficult about the job?
4. Why was the selected approach reasonable?
5. What result is actually documented?
6. What would a similar buyer need to confirm before hiring?

If the reviewer cannot answer, the draft may have too much field language, too little context, or too many unsupported claims. Fix the story before fixing the layout.

How should you maintain the case study after publication?

Maintain the source record and the public version together. Update the case study when a factual detail, customer approval, test interpretation, service offering, or regulatory link changes.

Set a review date based on risk:

• Review within 30 days if a result is tied to a short operating period or pending test.
• Review every six months if the page uses current regulations, forms, or active service details.
• Review annually for customer permission, contact details, technical links, and continued relevance.
• Review immediately if the customer asks for a change, the equipment is recalled, or a published statement is found to be incomplete.

Colorado's Division of Water Resources documents a 2026 change to its Well Construction and Yield Estimate eForm and the end of acceptance for older forms after May 1, 2026. Colorado DWR AskDWR. That is a useful reminder that a case study can outlive the form or process it mentions. Keep the story focused on the project and link to current requirements rather than embedding a stale filing instruction.

When a link changes, replace it or remove the related claim. When a customer withdraws permission, unpublish the identifying version and preserve an internal record of what was approved. When a metric is revised, explain the correction instead of silently changing a result.

What should a contractor do Monday morning?

Pick one completed project and build the evidence packet before writing a single headline. Score it for service fit, buyer similarity, records, measurement, decision value, permission, confidentiality, and territory fit.

Then use this order:

1. Gather the scope, field notes, well or pump records, tests, photos, changes, and handoff documents.
2. Mark every fact as documented, confirmed, estimated, or unavailable.
3. Write the snapshot and challenge in plain language.
4. Choose two or three decisions that explain the contractor's judgment.
5. Define the result with a baseline, date, method, and limitation.
6. Request a precise customer review and written publication approval.
7. Run the evidence pass and buyer pass.
8. Adapt the approved story for the proposal, service page, follow-up, and sales reference.
9. Link the story to the service page that matches the work.
10. Review the public version when the records, service, customer permission, or governing requirements change.

The case study is ready when it can answer a similar buyer's questions without pretending to know what the next site will produce. That is the standard. If you want to see whether your current proof, service pages, and territory visibility support more qualified calls, Brictale's free territory audit is the right next step.