Design the data schema for your outbound operation
Produces a complete data architecture for outbound: entity model, typed field dictionary with source-of-truth per field, stable cross-tool keys, legal lifecycle transitions, system write permissions, and a check that the schema answers your actual reporting questions. It's the difference between owning your data and renting fragments of it from five tools.
You are a data architect for GTM systems who has rescued dozens of outbound operations from schema debt: the CRM where 'lead source' has 47 free-text values, the operation where nobody can answer 'how many accounts have we ever contacted' because contacts live in four tools with no shared key. You design schemas boring enough to survive tool migrations. Design the data schema for my outbound operation. Output: 1. ENTITY MODEL — the core objects (Account, Contact, Campaign, Touch, Reply, Meeting, Deal) with a one-line definition each, and the relationships between them (one account has many contacts; one contact has many touches). 2. FIELD DICTIONARY — per entity: field name, type (picklist with allowed values, date, number, boolean — free text only where genuinely unavoidable), required or optional, and which system is its source of truth. 3. KEYS — the stable identifier for each entity across tools (domain for accounts, email for contacts, and what happens when those change), and the join logic between systems. 4. LIFECYCLE STATES — the allowed status values per entity and the legal transitions (a contact can't go from 'never contacted' to 'meeting held' without passing through touches; if it happens, data is lying). 5. SYSTEM MAPPING — which tool physically holds each entity, what syncs where, and what each tool is forbidden from writing. 6. REPORTING CHECK — confirm this schema can answer my five most important questions with a simple query each; if one can't be answered, revise until it can. Rules: every picklist gets a defined value set — free text breeds 47 spellings of 'LinkedIn'. Every field must name the report or automation that consumes it; fields nothing consumes get cut. Prefer fewer fields maintained well. Before designing, interview me. Ask ONE AT A TIME, waiting for my answer each time: 1. What tools currently store contact or account data, and roughly how many records in each? 2. What five questions do you most need your data to answer reliably? 3. What campaigns and channels do you run (email, LinkedIn, calls)? 4. Where does data currently disagree between systems? 5. Any compliance constraints — GDPR regions, suppression requirements, do-not-contact lists? Then produce the schema, and flag the top three migration risks from my current state.
How to use it
- 1
Copy the prompt into Claude, ChatGPT, or any LLM.
- 2
Answer question 2 first in your head — the five questions are the schema's acceptance test, so choose them carefully.
- 3
Implement the field dictionary in your CRM, deleting or hiding fields the schema cut.
- 4
Enforce it forward from day one, migrating historical data opportunistically rather than boiling the ocean.
Best practices
Fight every free-text field; each one is a future data-cleaning project with your name on it.
Write the forbidden-writes list into your integration settings, not just the doc — schemas enforced only by convention decay in weeks.
Keep the schema doc where the team works and treat changes like code changes: deliberate, logged, and rare.
When adding a tool, map it to the schema before connecting it — the mapping exercise reveals conflicts while they're still cheap.
Example: what this looks like in practice
A RevOps lead at a 50-person logistics-tech company can't answer 'which campaigns produced meetings that became revenue' because touches live in Smartlead, meetings in HubSpot, and the join between them is an SDR's memory. Her five questions include campaign-to-revenue attribution and total-addressable coverage. The schema comes back with seven entities keyed on domain and email, a Touch entity that both Smartlead and HeyReach write into HubSpot as timeline events with a campaign_id picklist, lifecycle transitions that expose the 300 contacts sitting illegally at 'meeting held' with zero logged touches, and a forbidden-writes rule stopping Clay from overwriting lifecycle stage. Three weeks of enforcement later, the attribution question is a saved report instead of a quarterly archaeology project.
Best fit
This prompt is one gear in a bigger machine. We orchestrate 20+ tools into outbound systems our clients own — and guarantee the results.
Apply for a Pilot Spot → →Frequently asked questions
Seven entities cover almost every operation: Account, Contact, Campaign, Touch, Reply, Meeting, and Deal, with stable keys (domain, email) linking them across tools. The Touch entity is the one most teams skip — and it's exactly why they can't answer attribution or coverage questions later. Model touches explicitly and the hard reports become simple queries.
More automation & workflow design prompts
Build a system prompt for an AI cold email reply agent
Interviews you about your offer, booking flow, and voice, then generates a complete production system prompt for an AI reply agent — classification taxonomy, response rules, escalation conditions, and a strict JSON output contract an n8n or Zapier workflow can parse. You get the artifact teams pay thousands to have written, tuned to how you actually talk.
Turn a manual sales process into an automation blueprint
Converts a fuzzy 'we do this by hand every week' description into a structured blueprint with a detectable trigger, labeled steps, edge cases, human checkpoints, and failure alerts. It forces the design decisions people usually discover mid-build, so what you hand to n8n, Zapier, or an ops hire is assembly work, not archaeology.
Architect a Clay table before you burn the credits
Designs the Clay table before you build it: sources, column order, run conditions, waterfalls, outputs, and a credit estimate. Column ordering and gating are where most teams silently overspend, so the prompt enforces filter-first architecture and makes every paid column defend its run condition — typically cutting credit burn 40-70% versus enrich-everything builds.