# LinkedIn ABM planner: FieldLedger example (fictional)

**Every FieldLedger name, person, account, capability, figure, asset, plan and later observation in this file is fictional.** This is a worked teaching example, not a real campaign or a performance forecast. The launch checks are deliberately open so the example shows how a ready draft can still be held.

## 1. Account and segment (all entries fictional)

| Field | Fictional FieldLedger answer |
| --- | --- |
| Business and first-test goal | FieldLedger shows closeout documents by project, complete/missing status, owner and next action. First test: help relevant contractors inspect an ungated closeout-handoff checklist. |
| Named-account list or selection definition; source and date | 50 US commercial mechanical contractors from a proposed account list. Luis must finish and date sales fit review. |
| Source account count; duplicates/entities still to resolve | 50 proposed companies; final entity validation **Unknown**. Luis reviews company identity and subsidiaries. |
| Why these accounts fit; supporting evidence | Their closeout process involves several project teams and document owners. This is the fictional selection hypothesis; account-level confirmation is **Unknown**. |
| Sales reviewer and date | Luis; final review date **Unknown**. |
| Customers and open opportunities | Luis checks the current CRM and decides which accounts need exclusion or separate sales treatment. Source and final decision **Unknown**. |
| Known contacts and buying roles by account; gaps | 18 named contacts across the 50 accounts; remaining role coverage **Unknown**. These contacts are CRM coverage, not a contact-list audience or delivery estimate. |
| Shared buyer problem and evidence | Proposed problem: missing closeout items and unclear handoff owners. The fictional product workflow can demonstrate this; customer-result evidence is not supplied. |
| First segment; changed action | Commercial mechanical contractors with the same closeout-handoff problem. Start with one shared account audience and two message executions for related role questions. |
| Deferred segments and reason | Separate ad sets by account, extra industry versions and retargeting are deferred until feasibility and response evidence support the work. |

## 2. Audience route and boundary (all entries fictional)

| Field | Fictional FieldLedger answer |
| --- | --- |
| Provisional route and why | Manual Company Names targeting in Build your own audience. The proposed 50 companies are below LinkedIn's 200-company manual selection maximum. This is a route to evaluate, not a completed audience. |
| Location and available roles | United States. Maya verifies the location definition and available selections for operations leaders and project-controls managers. VP of Operations, Director of Operations and Project Controls Manager are buyer-language candidates, not guaranteed targeting options. |
| Source rows / companies | 50 proposed companies. |
| Accepted upload rows | **Not applicable** to manual Company Names targeting. |
| Matched member accounts | **Not applicable** to manual Company Names targeting. |
| Final audience after all criteria | **Unknown**. Maya checks the saved selection after location, role criteria and exclusions. The final ad-set audience must meet LinkedIn's 300-member minimum. |
| Forecast and actual delivery | Forecast **Unknown**; actual delivery **Not applicable**, because this fictional plan has not launched. |
| Exclusions | Luis defines current-customer and active-opportunity treatment from CRM; Maya verifies supported employee and other exclusions in the selected mode. Saved checks **Unknown**. |
| Audience Expansion | Planned off where available to preserve the selected-account intent; saved setting **Unknown**. |
| Auto-Targeting | Planned manual Build your own audience. Saved mode **Unknown**; a list used as an Auto-Targeting signal would not establish a strict selected-account boundary. |
| Predictive audience | Not planned; saved status **Unknown**. |
| Saved summary and eligibility | **Unknown**. Maya records the criteria, final member audience and date before launch. Eligibility would not prove delivery. |

## 3. Message, offer and production (all entries fictional)

| Field | Fictional FieldLedger answer |
| --- | --- |
| Buying-role question A | Which closeout documents are still missing across active projects? |
| Message A | “See the missing closeout documents across your active projects.” |
| Proof and creative A | Proposed single-image ad with a legible fictional product screen showing project, document and status. Maya must check capability accuracy and permission for the final asset. |
| Buying-role question B | Who needs to do what next on each closeout item? |
| Message B | “Give every closeout item an owner and a next action.” |
| Proof and creative B | Proposed second single-image ad with a fictional product screen showing document, owner and next action. Maya must check capability accuracy and permission. |
| Offer | One ungated closeout-handoff checklist and completed example. Fields: project, document, required-by date, owner, status and next action. The completed row includes a missing item, an owner and next action. Asset completion **Unknown**. |
| CTA and post-click requirement | “View the checklist.” No form requirement is planned for viewing it; an optional product walkthrough may follow. Final behavior **Unknown** until tested. |
| Destination | Proposed checklist page. URL and working delivery **Unknown**; Maya builds and tests it. |
| Marketing, creative and sales-response owners | Maya owns campaign and creative; Luis answers explicit requests for help or a walkthrough. Nia owns CRM definitions and source capture. |
| Objective, ceiling and forecast | Provisional website visits objective. Fictional media ceiling $10,000 over 30 days. Cost and volume forecast **Unknown**; the ceiling does not promise spend or response. |
| Ad-account access, identity/Page/asset permissions and billing | **Unknown**. Maya verifies each required access and billing check separately and records evidence/date; pending or general access does not pass. |

The two messages address different questions. One ad set does not guarantee that each role sees only its corresponding message. No customer result or customer-results webinar is claimed.

## 4. CRM review and sales action (all entries fictional)

| Field | Fictional FieldLedger definition, source, period and owner |
| --- | --- |
| Account with reported paid exposure | Distinct account from the agreed target list with reported paid impressions in the chosen period; LinkedIn company reporting, reviewed by Maya and Nia. A suppressed value stays **Unknown**. |
| Explicit response | Recorded request or reply from an identifiable person, with source and requested action; CRM, owned by Luis and Nia. |
| Booked meeting | Scheduled meeting recorded in CRM; owner Luis. |
| Held meeting | Meeting Luis confirms actually took place; CRM. |
| Qualified held meeting | Held meeting where Luis records account fit, a relevant closeout problem and an agreed next step. |
| Opportunity | Accepted and recorded under the team's existing CRM rules; actual rule must be confirmed by Nia and Luis. |
| Won revenue | Closed-won opportunity value from CRM under the business's stated revenue definition; definition must be confirmed if used. |
| Campaign/source capture and response path | Nia submits a test request and confirms source and owner in CRM. Test result **Unknown**. |
| Sales feedback | For each account: observed signal, source, period, existing relationship, owner and proposed action. Company engagement alone never identifies a person. |
| First joint review and next decision | Maya, Luis and Nia plan day 14; calendar date **Unknown**. Check delivery, explicit response and sales feedback separately. Repair a broken response path immediately. |

If a person explicitly asks for the checklist, Luis sends it and asks which closeout handoff is difficult. Company-level activity without a named request calls for account-fit review, not a claim that a particular contact clicked.

## 5. Decision record (all entries fictional)

| Status or open item | Fictional FieldLedger answer |
| --- | --- |
| Draft status | **Draft Ready** for creative and audience preparation. The fictional account hypothesis, buyer problem, offer, provisional route, messages and owners are coherent; live checks are assigned. |
| Launch status | **Launch Hold**. Final list, audience, boundaries, asset permission, destination and CRM tests have no passing evidence. |
| Final account list and fit review | **Unknown**. Luis validates entities, fit and customer/opportunity treatment. |
| Final audience, mode, criteria, exclusions and expansion | **Unknown**. Maya checks and records saved summary and final member audience. |
| Claim permission, accurate and legible creative | **Unknown**. Maya reviews final product screens and copy before release. No customer-result claim is allowed from the supplied facts. |
| Ad-account, Page/identity/asset permissions and billing readiness | **Unknown**. Maya records each required authorization and billing check separately. |
| Working destination and offer delivery | **Unknown**. Maya opens the final page, receives the checklist and confirms it matches the ad. |
| CRM source capture and response assignment | **Unknown**. Nia sends a test request and checks source and owner in CRM. |
| Ceiling, review and response owner | Fictional ceiling $10,000/30 days; Luis is proposed response owner; joint day-14 review is proposed. Agreement and calendar date **Unknown**. |
| Next action | **Validate audience feasibility** while producing the two creative concepts and checklist. Keep Launch Hold until every applicable check passes. |

The fictional post-launch figures discussed in the article are a separate teaching scenario after hypothetical checks have passed. They are not forecast inputs and do not change this prelaunch **Launch Hold** record.

State rule used in this example: missing core account, fit, problem, offer, route, role or owner inputs would produce **Draft Hold**. A coherent plan with assigned next checks can be **Draft Ready**. **Launch Ready** requires passing evidence for every applicable live check; any failed, blank or literal **Unknown** launch check remains **Launch Hold**.