Skip to content
NEW: Martech Stack Builder on your phone →

No more “who approved this vendor?”

Marketing buys a tool. IT finds out when an integration breaks. Finance gets the invoice. And nobody can say who agreed to it, or why. Stack Builder gives every change to the stack one place to happen: a change request that runs from draft to decision to done, with a record at the end.

One change request, from draft to closed

Write it, get the votes, apply it to the stack with a way back, track the work, and close it with the outcome on the record.

A change request from draft to closed. The draft names the change, the reason and the approvers, with a readiness list. Approvers vote in the room, by email or on a phone, until all four have approved. Apply shows the affected part of the stack before and after, updates it, and offers Revert this change. Track lists the tasks with owners and due dates. Close records the outcome, done as planned, with who decided and when.

The governance gap

Code has pull requests. Infrastructure has change management. Data has access controls and lineage. The martech stack, often one of the bigger lines in the marketing budget, usually has a Slack thread and a hopeful spreadsheet.

That’s not a discipline problem. Nobody wants to fill in a form to swap one email tool for another. So the form has to do most of the work itself: know the stack, work out who’s affected, chase the people who owe a vote, and remember what was decided after everyone has moved on.

How a change request runs

Every change request moves through the same five stages, and the room shows you which one it’s in and what it’s waiting for.

  1. Draft

    Pick the stack and the kind of change: a tool, a data flow, ownership or a governance change such as a data policy, an access change or a contract renewal. Fourteen types in four groups. The engine fills in what it already knows from the stack, scores the impact from the tools involved: how central they are, what they cost, how many departments they reach, and whether personal data or critical connections are in play. It marks what’s still missing before you can submit, and the draft saves as you go.

  2. Review

    The approvers vote: approve, request changes with a note, or abstain. The request passes on the rule you chose in the draft: all approvers, a majority, or a single approval. If someone asks for changes, the author revises and resubmits. Approvers who haven’t voted can be reminded with one click.

  3. Apply

    Once it’s approved, the room shows the stack before and after on a small canvas. Apply writes the change to the stack, after saving a version first, so it can be reverted within seven days.

  4. Track

    The work after the decision becomes tasks with an owner and a due date. Whoever has the task gets an email the day before it’s due and another once it’s overdue. If that’s not enough, nudge them: a notification and an email (at most once per task every 48 hours, so it stays a nudge and not a nag).

  5. Closed

    Close it as done as planned, done with changes, or dropped, with a note. That’s the closing record: what changed, who decided, what happened and who closed it, and it can be reopened within 30 days.

A change request at the Draft stage, “Replace Twilio Segment with RudderStack”: the five stages across the top, the type, title and reason filled in, and a readiness list that names the one thing still needed before it can be submitted, the approvers
The change request library: six requests on one stack, one at each stage from Draft to Closed, with the tool each one takes out or brings in, who wrote it and the next action, such as an overdue task or a vote that is needed
Every change request in the workspace, with what it is waiting for
The Apply stage: the affected part of the stack before and after, with the new Snowflake to Braze flow drawn in green, and who may apply it
Apply: before and after, then one click
The Track stage: six tasks with owners and due dates, one done, one overdue by 3 days, one waiting on another, with Nudge buttons and how the reminders work
Track: owners, dates and reminders

The Inbox: what’s waiting on you

Who goes looking for change requests? Not approvers, and not the people with tasks either. So the Inbox brings them in. It shows the decisions waiting on you, your tasks with the overdue ones first, and mentions and replies from the discussions you’re in. Owners and admins also get a team view of who’s carrying what.

The Inbox is on every plan, and on your phone, where you can vote on a change request between meetings.

The Inbox: a vote on a change request and an RFI to score under Needs your decision, two tasks with the overdue one first, and a mention from a colleague, each with its due date and a button to act on it

Approvers outside the workspace

Procurement, legal, finance. They don’t want another login, and they shouldn’t need one. Add an outside approver by email and they get a personal link to a page with just the change request on it. They approve, request changes or abstain, with a note, and can change their vote while the request is open. Their vote is recorded on the request with their name, the time and what they wrote.

A change request in Review: your Approve, Request changes and Abstain buttons, the rule “All: 4 of 4 must approve, 3 so far”, and each approver with their note and timeline, the last one an outside approver from group finance whose link shows sent, delivered, opened and voted

Discussion in context

On Team, Agency and Enterprise, each change request has its own discussion. Replies stay threaded, and anyone you @mention is notified. Outside approvers don’t post in the discussion; their note travels with their vote.

Ownership

Every tool can belong to a department with a lead. The Owner lens colours the stack by who’s responsible, so the tools nobody owns stand out.

The Owner lens: every tool on the stack labelled with its department, and a legend showing 10 of 10 tools assigned across four departments, each with its lead

Roles

Owner, Admin, Editor, Viewer and Approver roles decide who can change what, and the database checks them, not just the screen. Approvers don’t take a paid seat. Members and roles live in Settings › Workspace › Members.

Settings › Workspace › Members: six people, each with their role (Owner, Admin, Editor or Viewer), and 6 of 10 seats used

The method

Establish governance by hand

Governance fails when it is written as policy and never as a check someone runs. This procedure produces a small number of checks with names attached. A day to write, an hour a month to run.

  1. List every tool that touches personal data

    Not every tool — the ones holding or receiving anything identifying. Be generous about what counts: an email address in a support tool is personal data.

  2. Trace consent from collection to use

    For each of those tools, write where the consent came from and what it permits. Where you cannot complete the sentence, you have found a gap — and it is better found by you than by a regulator.

  3. Name an owner per tool, not per policy

    One person per tool who is accountable for its data. Policies without per-tool ownership are how a stack ends up compliant on paper and not in practice.

  4. Write the three checks you will actually run

    Three that get run beat twenty that do not. Good candidates: new tools added since last review, consent-string coverage on the highest-traffic path, and access for people who have left.

  5. Put the review in the calendar with the owners invited

    An uncalendared review is a document. Monthly or quarterly; the cadence matters less than it existing.

Worked example Illustrative

European retailer, 19 tools, 11 touching personal data.

Tools touching personal data 11
Consent path fully traceable 6 / 11
Tools with a named owner 4 / 11
Added since last review 3
Retained access, departed staff 2 tools

Reading it: Five untraceable consent paths is the compliance headline, but four named owners out of eleven is the cause. Ownership is the fix that makes the other numbers move.

The shortcut: The Consent and PII Data lenses show step 2 across the diagram, so the gaps surface as you build rather than during an audit.

Frequently Asked Questions

What is martech governance?
The way a team decides what goes into the stack, who owns each part and how changes are approved, with a record of the decisions. It keeps you from paying for the same capability twice and from finding out about a new tool when something breaks.
Which plan do I need?
Full change requests with approvers, discussion and roles are on Team ($35 a seat a month), Agency (in every client workspace) and Enterprise. Consultant includes solo change requests: you plan, apply and track your own changes, without a review stage. The Inbox is on every plan.
Can we customise the approval workflow?
Partly. Each change request names its approvers, members of the workspace, department leads or people outside it by link, and one rule: all approvers, a majority or a single approval. Multi-stage workflows aren’t available.
Is there an audit trail?
Yes. Votes, comments, applies and the closing record are kept with who and when, saved versions keep the history of the stack, and member, role and sharing changes appear in the workspace audit log (30 days on Team, 365 on Enterprise).
Does it work with Slack?
Yes. Connect Slack to a team workspace and new change requests post to a channel with Approve and Request changes buttons, so approvers can vote without opening the app. Microsoft Teams isn’t supported.
Can the tasks go to JIRA?
Yes. Push a change request’s tasks to JIRA from the Track stage; each one becomes a sub-task, and pushing again updates them.

Start governing your stack

Every stack change as a change request, from draft to closing record, with an Inbox for what's waiting on you.

No credit card required. Free plan available.