When a generic module isn't enough: building your own

The built-in modules cover the most common marketing workflows: campaign concepting, content strategy, brief development. For teams whose work fits those patterns, the built-in modules handle the process without any additional setup.

Some teams have workflows that are specific to their situation. A particular client intake process. A recurring content audit structure. A competitive positioning review that follows the same steps every time. Generic AI chat handles these well enough on a good day — but on a day when the prompter is rushed, or when a new team member runs the session, or when the process hasn't been used in a few months, the output reflects the variance in the inputs.

What makes a workflow worth encoding as a module

Not every recurring task benefits from a dedicated module. The investment makes sense when a workflow has all of the following properties.

Fixed structure. The workflow has a specific sequence of steps where later steps depend on earlier ones. The order matters. Skipping a step or reversing the sequence produces a worse outcome. If you have run the workflow several times and the sequence is always the same, that structure can be encoded.

Recurring use. The workflow runs repeatedly — weekly, monthly, or at least predictably across projects. A workflow that runs once or twice a year may not justify the build investment. A workflow that runs every time a new client is onboarded, every time a quarter-end report is produced, or every time a campaign is launched is worth encoding.

Inconsistent results without structure. If the quality of the output depends heavily on who runs the session and how carefully they prompt, the workflow is a candidate for a module. A module removes that dependence by encoding the structure in the platform rather than leaving it to each prompter to apply correctly.

What a custom module contains

A custom module is a set of instructions that define how AI should approach a specific workflow. The instructions encode:

The workflow stages. Each stage of the process, in order, with a description of what the AI should do in each stage and what information it needs before moving to the next. Stages that require user input are structured as questions or prompts; stages where AI synthesizes previous inputs are marked accordingly.

The entry conditions. What information needs to exist before the workflow begins. A competitive review module might require the team to specify which competitors are in scope and what evaluation criteria matter. Getting this information before the workflow starts rather than mid-process produces better outcomes.

The output format. What the module should produce at the end: the structure of the deliverable, the level of detail required, the format of the final output (brief, analysis, checklist, recommendation). Encoding the output format in the module ensures consistency across every session, regardless of who runs it.

The constraints. Any rules the workflow must follow. Terminology that must appear in certain sections. Claims that require sourcing. Steps that require explicit approval before the AI proceeds. These constraints can be captured in the module instructions rather than prompted each session.

How to build one

The custom module builder in Copper Sun's platform starts with a co-authoring session where you describe the workflow you want to encode. The co-author asks clarifying questions about the stages, the entry conditions, the output format, and the constraints — the same information listed above, but surfaced through a structured conversation rather than a blank document.

After the co-authoring session, a draft module is produced. You test it against a real instance of the workflow, evaluate where it performs well and where it needs adjustment, and iterate from there. The co-author assists with refinement — adjusting stage transitions, tightening output format specifications, adding constraints that the test session revealed.

When the module reaches the quality bar your team needs, it is available in the platform alongside the built-in modules. Any team member can use it. Every session using it starts at step one of the same defined workflow.

When a custom module is not the right solution

There are situations where building a custom module does not pay off.

When the workflow is still evolving. If the team is still learning how to do the work and the process is changing with each iteration, encoding it as a module locks in an approach that may not survive the next project. Wait until the process is stable before encoding it.

When prompting is genuinely sufficient. Some workflows are simple enough that a well-written prompt template handles them reliably. The question to ask: does the workflow have more than three distinct stages? Does it require information gathered at different times in the process? If not, a prompt template may be the right tool.

When the workflow is person-specific. If the workflow depends on judgment calls that differ significantly by practitioner and that variation produces legitimately different good outputs, a module may impose too much structure. Modules are for processes where the structure produces better outcomes; they are not for creative processes where individual variation is the point.

Frequently Asked Questions

How long does it take to build a custom module?

A co-authoring session to produce a draft typically takes 30 to 60 minutes. Testing the draft against a real workflow instance takes however long the actual workflow takes. Refinement after testing usually requires one to two iterations. Total investment from blank slate to deployed module is typically two to four hours for a moderately complex workflow.

Can the module be updated after it's deployed?

Yes. Module instructions can be revised at any time. Revisions apply to new sessions immediately; existing sessions that started before the revision continue using the version they started with. This means you can update the module when the workflow evolves without disrupting in-progress work.

Who can build and edit custom modules on the platform?

Module building and editing is available to users with appropriate platform access. Built and edited modules are available to the whole team — you build once, the whole team benefits. There is no per-user module configuration; the module is a shared platform resource once deployed.

Can a custom module reference or connect to a built-in module?

A custom module can be designed to follow or precede a built-in module in a workflow. For example, a custom client intake module can collect information that then flows into the Campaign Concepting module for the first campaign project. Module handoffs carry context from one module to the next, so the output of the custom module becomes the input for the built-in one without manual re-entry.