Agencies often describe productization as a way to “build once and sell many times.” That phrase skips the hard part: deciding what is actually reusable. A proposal workflow may recur across clients, but qualification criteria, approval owners, required information, and exceptions can differ enough to make a copied setup unreliable.
The practical goal is narrower and more useful: reduce repeated setup without pretending that every client operates the same way. A template can give the team a tested starting point. It cannot replace discovery, agreement on responsibilities, or a real test with the client’s process.
Map the recurring process before selecting a template
“Build a template for dentists” is a broad starting point. “Help appointment-based businesses capture a request, confirm the service, assign an owner, and follow up” describes work that can be inspected and tested.
Before configuring software, map one process that appears repeatedly in your engagements. Write down five things:
- Trigger: What event starts the work?
- Inputs: What information is needed before someone can act?
- Decision: Who decides what happens next, and using which criteria?
- Handoff: Who receives the work, and what must they know?
- Exceptions: What common case falls outside the usual path?
Keep the first version small. If the team cannot explain a workflow step in plain language, putting it in a template will not make it clearer. If clients use the same label for different decisions, the label is not yet a stable standard.
Separate the stable core from client configuration
For each step, sort the details into three groups:
- Stable core: the sequence, handoffs, and minimum information that remain useful across clients.
- Client configuration: names, service categories, qualification questions, ownership, and timing that must be agreed with a particular client.
- Custom work: exceptions or requirements that change the process materially and need separate scope, approval, or implementation.
This distinction prevents two common problems. The first is over-customizing every new account until there is no reusable process. The second is forcing a client into defaults that do not match its work.
A simple example is a service inquiry. The shared process is straightforward: someone receives the inquiry, checks the information, assigns a responsible person, and records what should happen next. One client may need a site visit before a quote; another may need a technical review. Those differences belong in configuration or a defined exception, not in an unsupported promise that one funnel fits both.
Bolten’s current documentation describes a “Modelo” as a preconfigured set of brand, price, tools, and visual identity. It also says the model is a starting point for selecting an environment appropriate to a client’s needs. That is useful deployment infrastructure, but it does not decide which business process is suitable or prove that a template fits a particular operation. See Bolten’s client creation and customization guide. (Bolten — Sales and Ads model guide)
Make the template usable by someone other than its author
A template is not ready merely because it works for the person who built it. Another team member should be able to answer, without guessing:
- What starts this workflow?
- What information is required at each handoff?
- Who owns the next action?
- What counts as complete?
- Which cases must be escalated or handled outside the standard path?
- Which settings are client-specific, and who approved them?
Document these answers where the operator will use them. Keep labels short, avoid duplicate fields, and make “unknown” an acceptable state when a fact has not been confirmed. Do not add a field because it might be useful someday; add it when someone needs it to make a decision or complete a handoff.
The same principle applies to onboarding. Tell the client what they must provide, what your team configures, what the client must validate, and what is outside the agreed scope. This makes the template part of a service process rather than a software handoff with hidden assumptions.
Test the actual client journey before sharing a model
A test should cover the path a client and an operator will actually follow—not just whether the configuration screen looks tidy. Use a short acceptance checklist:
- Can the intended user understand the first screen and the next action?
- Are the fields and labels meaningful in the client’s language?
- Can an inquiry reach the right person without relying on undocumented knowledge?
- Are missing information and exceptions handled clearly?
- Does the client see only the tools and settings intended for that project?
- Can the client and agency agree on what “ready” means before launch?
Bolten documents two distinct checks: an editing view for visual review and a practical test using the demo project or the model’s invitation link to experience the client journey. The visual view is not a working environment for final operations. Use the practical path to validate behavior, and confirm current instructions in Bolten’s model testing guide.
Treat a successful software test as one part of acceptance. It does not confirm that the client’s staff have adopted the workflow, that every exception is covered, or that the process has improved business results. Those questions require observation after launch and feedback from the people doing the work.
Version the template and plan for existing clients
A template changes as the agency learns. Record what changed, why it changed, when it took effect, and which new client engagements should use it. Keep a concise changelog so a new operator can distinguish current defaults from older decisions.
Also decide how to handle active clients before changing the master. Bolten’s documentation says general model changes define the standard for new clients and are not applied retroactively; changes to an active client’s project are made individually. That means a master update alone does not update every live deployment. Maintain a client-by-client record of relevant variations and decide whether a change is worth applying to each one. The details are in the customization guide. Confirm current behavior in the account before applying a template change.
Do not measure productization only by how quickly the next template can be copied. Track the work that determines whether the service remains sustainable: initial setup time, client-specific changes, support requests, exceptions, rework, and time spent maintaining active projects. Compare those measures across engagements, but interpret them in context. A more complex client may require more adaptation for good reasons.
A practical first release
For the next workflow you want to standardize, use this sequence:
- Select one recurring process with a clear start and finish.
- Observe how the work is performed and confirm the steps with the people involved.
- Mark each element as stable core, client configuration, or custom work.
- Build the smallest template that supports the stable core.
- Write the handoff, ownership, required inputs, and exception instructions.
- Test it through the user journey and fix confusing or incomplete steps.
- Review it with the client before launch and record approved variations.
- Version the master, then separately assess any change for active clients.
- After launch, review setup effort, support, exceptions, and rework before calling the template reusable.
A good template does not make every client identical. It makes repeated work easier to recognize, explain, and deliver—while keeping differences visible enough to manage. That is a more realistic basis for a productized service than promising that one configuration will eliminate custom work.
