Consultants who serve contractors often notice the same thing: the fifth prequalification or the tenth ISO gap analysis looks a lot like the first. The client changes; the method doesn't. You ask for the same documents, run the same checks, spot the same gaps and write a report with the same structure.
That repeatable method is your most valuable asset, and most of it lives in your head. This guide shows how to get it out: how to break an engagement into steps, inputs, outputs and decision points, what to leave to human judgement, how to capture templates and examples, how to test the result against past work, and how to version, price and protect it. It ends with a step-by-step plan. Some of it is specific to publishing a blueprint on the Qonstrue Community, but the method is worth doing even if you never publish anything.
What a blueprint is on Qonstrue
The Qonstrue Community lets experts publish two kinds of listing that organisations install into their own Qonstrue workspace:
- A skill is a focused set of written instructions, with supporting files, that an AI agent follows to do one job well. For example: "review a health and safety policy statement against these criteria".
- A blueprint is a workspace template built around a whole service. It carries your instructions, which apply to every workspace created from it; the skills it relies on; the integrations a user is prompted to connect; starter prompts for its common use cases; and documentation explaining how to use it.
An organisation installs a blueprint and creates a workspace from it. The work then happens in their workspace, on their documents. Some blueprints are set up instead to run against one saved record at a time, such as each supplier on a list, with a short description you write of what will happen, shown before it runs.
You build and test in your own sandbox organisation before anyone else sees your work. A listing starts as a draft; each upload becomes a version that goes through automated validation, and it's then submitted for review and published. Buyers see your listing's description, documentation, output examples, version history with changelogs, reviews and your expert profile.
In practice, that maps onto a consulting engagement like this:
| Your engagement | In a blueprint |
|---|---|
| How you explain the job and the way you work | The blueprint's instructions and documentation |
| Each distinct task you perform (check a policy, score a statistic, draft a section) | A skill |
| The systems you ask the client for access to | Integrations the user is prompted to connect |
| The questions clients usually bring you | Starter prompts for common use cases |
| Your report format and sample reports | Templates in the skill files, and examples on the listing |
| Your CV and credentials | Your expert profile |
Why codify a method at all
Even with no plan to publish, writing your method down pays off:
- Consistency. Every client gets your best version of the check, not the one you remembered on a busy Friday.
- Delegation. A junior colleague can run the predictable parts and bring you the exceptions.
- Scope control. A written method makes it obvious when a client asks for something outside it, which helps you price the extra.
- Less key-person risk. If you're ill or fully booked, the method still exists.
- Better pricing conversations. It's easier to sell a defined service with defined outputs than an open-ended day rate.
Published, it also gives you a route to clients you would never otherwise meet, and visible signals (installs, reviews) about which parts of your expertise the market values.
Step 1: find the repeatable core
Pull out your last five engagements of the same type. For each, list:
| Look for | Example (prequalification readiness review) |
|---|---|
| The inputs you always ask for | H&S policy, safety manual, insurance certificates, accident statistics, training matrix, previous submissions |
| The checks you always run | Policy signed, dated and reviewed in the last 12 months; certificates name the right legal entity; incident rates recalculated from the raw figures |
| The decisions you always make | Is this gap a blocker or a recommendation? Which scheme suits this client? |
| The outputs you always produce | Gap report with red/amber/green ratings, an action list, a renewal calendar |
| The questions clients always ask | "Which accreditation do we need?" "Why did our submission get rejected?" |
Whatever appears in all five is the core. Whatever appears in only one is probably judgement or a one-off, and that's fine: note it, but don't build it in yet.
Step 2: decompose the engagement into steps
Write the method as steps, not prose. Each step should be small enough that you could hand it to a capable new colleague with a page of instructions. For each one, capture five things:
- Input. What it needs, and what to do if it's missing.
- Action. What to do, in plain terms.
- What good looks like. The criteria you actually apply. This is where your expertise lives, so be explicit.
- Output. What the step produces, in a fixed format.
- Owner. Whether it can run unattended, needs review, or needs you.
Here's a fragment of a prequalification readiness review written that way:
| Step | Input | What good looks like | Output | Owner |
|---|---|---|---|---|
| 1. Check the H&S policy statement | Policy document | Signed by a director, dated, reviewed within 12 months, names responsibilities | Pass / fail per criterion, with the page reference | Automated, reviewed |
| 2. Check insurance | Certificates | Named insured matches the legal entity exactly; in date; limits meet the target scheme or client minimum | Table of policies, limits, expiry dates and issues | Automated, reviewed |
| 3. Recalculate incident rates | Incident log, hours worked | Rates match the hours and counts provided | Recalculated rates and any discrepancy | Automated |
| 4. Rate each gap | Outputs of steps 1 to 3 | Your rubric: what makes a gap red, amber or green | Rated gap list | Reviewed |
| 5. Recommend a route | Client's sector, target clients, gap list | Your judgement on which schemes and in what order | Short recommendation with reasons | You |
Write decision points as rules
Wherever you'd normally say "it depends", work out what it depends on. "If the policy is unsigned, rate red. If it's signed but more than 12 months old, rate amber. If the client works on sites where the principal contractor imposes stricter rules, check those first." Rules like these are what make a method transferable.
When you can't write the rule, that's a signal: either the decision is genuine judgement, or you haven't yet worked out what you're doing. Both are worth knowing.
Say what to do when inputs are missing
Real engagements are messy. Decide in advance: does a missing document stop the process, get flagged and skipped, or trigger a request to the client? Write it down. A method that only works with perfect inputs won't survive the first real client.
What stays human judgement
A good blueprint is honest about its limits. Keep these with a person, and say so in the instructions and documentation:
- Interpreting ambiguous or conflicting requirements, such as a client's questionnaire that contradicts the scheme it claims to follow.
- Anything that reads like legal advice: whether a duty applies, whether a contract term is acceptable.
- Risk acceptance: deciding a gap is tolerable for now.
- Sign-off and commitments: declarations, policy approvals, anything that binds the business.
- Novel situations your five past engagements never covered.
- Conversations: getting a site manager to explain how incidents are really reported.
Build the hand-off into the method. "If the client operates in more than one jurisdiction, stop and recommend specialist review" is a feature, not a weakness. Buyers trust a method more when it tells them where it ends, and for a consultant, that hand-off point is where paid work begins.
Capture templates and examples
The quality of your output depends heavily on what you show, not just what you tell. Collect:
- Output templates: the exact headings, tables and rating scales of your report.
- Gold-standard examples: one or two finished deliverables you're proud of, fully anonymised.
- Good and bad examples for your trickiest checks: a policy that passes, one that fails, and why.
- Rubrics: your scoring criteria, written out as a table.
- A glossary of terms clients confuse, such as the difference between a policy, a procedure and a record.
On Qonstrue, templates and reference material travel as files inside your skills, and listing examples (screenshots, images, video or sample output written out as text) show buyers what they'll get before they install.
Anonymise properly. Remove client names, people's names, addresses, policy numbers and project names, and anything that would let a reader identify the client from context. If in doubt, rebuild the example from scratch using a fictional company.
Test it on past engagements
Before anyone else sees it, run your method on engagements where you already know the right answer.
- Pick three to five past cases, including at least one messy one: missing documents, an unusual structure, a client that failed.
- Run the method as written, without filling gaps from memory. If you're using Qonstrue, do this in your sandbox organisation.
- Compare the output with what you actually concluded. Log every difference.
- Classify each miss: a missing rule, a vague criterion, a bad template, or genuine judgement that should be a hand-off.
- Fix and rerun until the differences are ones you can live with.
- Have someone else run it, ideally a colleague who doesn't know the cases. Where they get stuck is where your instructions are unclear.
A simple log keeps you honest:
| Case | What I concluded | What the method produced | Cause | Fix |
|---|---|---|---|---|
| Groundworks firm, 2025 | Insurance entity mismatch: red | Missed it | Check compared trading name, not legal name | Rule now compares registered company name |
| Electrical subcontractor | Accident rate fine | Flagged as high | Hours excluded subcontractor labour | Instruction now asks which hours are included |
Version it like a product
Methods change: schemes update their questions, standards are revised, and you learn from each engagement. Treat every change as a release.
- One change log entry per version, in plain language: what changed, why, and whether outputs will look different.
- Change rules deliberately. If you tighten a criterion, say so, because a client who passed last month may now see an amber.
- Review on a schedule, for example every quarter, and whenever a standard or scheme you rely on changes.
On Qonstrue, each uploaded version is a fixed snapshot with its own changelog, shown on the listing. Organisations that have installed your blueprint can see when a newer version is available and update, or choose to update automatically. That makes the changelog the main way you communicate with your users, so write it for them.
Price and position your expertise
Positioning
Narrow beats broad. "Health and safety compliance" competes with everyone. "Prequalification readiness review for small groundworks contractors working towards SSIP accreditation" tells the right buyer instantly that it's for them. Your listing should answer:
- Who it's for: trade, size, region, the clients they sell to.
- What it produces: the actual deliverable, with an example.
- What it doesn't do: where human review or your direct support is needed.
- Why you: credentials, years in the field, the kinds of clients you've served.
Your expert profile carries your headline, background, credentials, industries and regions, and verified experts carry a badge. Writing Insights posts about the problems your blueprint solves is a natural way to show your thinking to the people who'd buy it.
Pricing
Listings can be free, a one-off price or a subscription. At the time of writing, Qonstrue's publishing pages state that experts keep 85% of each sale, with a 15% platform fee; check the current publisher terms before you set a price.
| Model | Suits | Watch out for |
|---|---|---|
| Free | Building reputation; a front door to your consulting; a narrow skill | Support expectations still arrive |
| One-off | A stable method that rarely changes | No income for the updates you'll still make |
| Subscription | Methods tied to schemes, standards or rules that change, where your updates are the value | You must actually keep updating |
A useful way to think about price is the time and risk it saves the buyer, compared with doing the job unaided or commissioning it from scratch, not your hourly rate. And remember that a blueprint can bring you consulting work: the buyer who hits your "stop and refer to an expert" step already knows your name.
Protect what's yours
Be clear-eyed about what you're sharing.
- What leaves you is the published bundle, and nothing else. On Qonstrue, your sandbox workspace and its knowledge base stay private, and nothing from a buyer's workspace flows back to you.
- Assume buyers can read everything in the bundle. They receive a copy in their own organisation. Decide deliberately what goes in: the method and the checks, yes; client files, never.
- Keep secrets out. Validation checks bundles for embedded credentials such as API keys, but it can't spot a client's confidential information. That's your job.
- Don't republish others' content. Standards such as ISO 9001 are copyrighted. Reference clause numbers and paraphrase the intent; don't paste the text. The same goes for client templates and scheme question sets you don't own.
- Read the publisher agreement before you publish, and take advice if your method draws on material you developed under a past employment or client contract.
Ultimately, your edge isn't secrecy. It's keeping the method current, the judgement you bring to the hand-off points, and the reputation that comes with your name on the work.
Common mistakes
- Writing prose instead of steps. A narrative of how you work isn't a method another person, or an agent, can follow.
- Leaving "what good looks like" implicit. "Check the policy" is not an instruction; "signed, dated, reviewed within 12 months" is.
- Trying to automate judgement. Hand-offs make a method more trustworthy, not less.
- Testing only on easy cases. Your messiest past client is your best test.
- Leaking client details in examples.
- Shipping changes silently. Users who see different results with no changelog stop trusting the output.
- Positioning too broadly. If it's for everyone, nobody recognises it as theirs.
A six-week plan
Week 1: audit. Pull five past engagements of one type. Build the inputs, checks, decisions and outputs table.
Week 2: decompose. Write each step with its input, action, criteria, output and owner. Turn every "it depends" into a rule or a hand-off.
Week 3: capture. Build the output template, rubric and one anonymised gold-standard example.
Week 4: test. Run the method on three past cases. Log and fix every miss. Have a colleague run one.
Week 5: package. Write the documentation: who it's for, what it produces, what it doesn't do. If publishing, set up your expert profile and build the blueprint in your sandbox organisation.
Week 6: release. Publish version 1 with a changelog, or put it to work internally. Book a review date for next quarter.
Start here
Pick the engagement you've done most often in the last year. Pull out the five most recent examples and fill in the table in step 1. It takes an afternoon and shows you, in one page, how much of your work is method and how much is judgement. Whether you publish it on the Qonstrue Community or just hand it to your next hire, that page is the start of a method that works while you're busy.
Your method already works. A blueprint just means it can work without you in the room.