GTM Engineering: What to Automate—and What to Fix First

A prospective client finishes a discovery call with a digital marketing agency. They want more qualified enquiries, a better website and help making sense of their advertising spend.

The account director has the recording. The founder has a view on pricing. The delivery leads need to estimate the work. Someone has to turn all of that into a proposal.

A few days later, the document is still being passed around.

An AI tool could produce a first draft in minutes. But what should it include? Which services address the client’s problem? What can the team deliver within the budget? Who has checked the scope?

The writing is one part of the work. Much of the delay comes from decisions that haven’t been made.

Consider this a hypothetical agency. Its situation gives us a useful way to examine GTM engineering: what needs to be clear before a business can automate the work of winning customers?

What is GTM engineering?

GTM engineering connects the data, software and workflows a business uses to find, win and keep customers.

For a service business, that might mean organising account research, preparing proposals, coordinating follow-up or transferring an agreed scope to the delivery team. The work combines an understanding of how the business sells with the ability to build systems around that process.

The starting point is a specific commercial task. Before automating it, you need to understand the decisions, information and people it depends on.

If you’re still choosing which task deserves attention, start with our guide to finding the growth bottleneck. Here, we’ll look at what happens after you’ve identified a process worth improving.

Define the task before choosing the tools

For the agency, “automate proposals” sounds straightforward until different people describe what they expect.

The founder wants proposals sent sooner. The account director wants less administrative work. Delivery wants fewer commitments made without its input. Finance wants consistent pricing and payment terms.

A useful first scope could be:

Prepare a proposal draft from an approved discovery brief, using the agency’s current services, pricing rules and scope template. Flag anything that needs a decision before the proposal can be sent.

That description establishes both the job and its limits. The system can assemble what is known and make unanswered questions visible. It doesn’t have to invent an answer just to finish the document.

Put the decisions in the right order

A proposal depends on several decisions made upstream.

The recommended work depends on the client’s problem. The price depends on the scope. The start date depends on capacity. Follow-up depends on whether the client has replied or asked for changes.

Mapping those dependencies helps the team decide what to fix first.

Before you automate…	Establish this first	What can go wrong otherwise
Discovery-call summaries	Which facts matter, and how to distinguish requests from agreed commitments	Something mentioned in conversation becomes part of the promised scope
Service recommendations	What the agency offers, who each service suits and what evidence supports the recommendation	Every prospect receives a variation of the same package
Proposal pricing	Approved rates, assumptions and discount authority	A convincing proposal contains work the agency cannot deliver profitably
Start dates	Available capacity and who can commit it	Sales promises a kickoff the delivery team cannot support
Proposal follow-up	Current status, ownership and stop conditions	The client receives reminders while waiting for an answer from the agency
Delivery handover	The accepted scope, exclusions and outstanding dependencies	Delivery begins from a different understanding of what was sold

You don’t need to redesign the whole agency before building anything. You need enough agreement for the particular workflow you want to improve.

Capture what the client actually said

A discovery call contains different kinds of information.

There are facts: the client’s current spend, existing systems and available team. There are preferences: they would like a new website or more frequent content. There are unresolved questions: perhaps nobody knows whether the lead-quality problem comes from targeting, the offer or the way enquiries are handled.

A useful brief preserves those distinctions.

If a client says, “We might want to launch in another market later,” the proposal should not quietly include an international launch. If the salesperson suggests a possible result, the summary should not turn it into a guarantee.

AI can help organise a transcript, but the account owner should check the brief before it becomes the basis for pricing and scope.

Corrections are cheaper here than after the client has received a polished document.

Decide which information the workflow should trust

Agency knowledge can be scattered across old proposals, spreadsheets, chat messages and people’s memories.

Last year’s proposal may contain an attractive price that no longer makes sense. A service description may refer to a deliverable the team has stopped offering. A standard timeline may assume that the client supplies assets immediately.

Choose a maintained source for the information the workflow uses. At a minimum, that may include:

• Current service descriptions and scope boundaries.
• Approved pricing rules and commercial terms.
• Delivery requirements and capacity confirmation.
• The client’s reviewed discovery brief.

Also give someone responsibility for keeping each source current.

Without that ownership, the automation will keep using whatever it can find. The output may look consistent while becoming less accurate over time.

Keep commercial judgement visible

Some decisions can follow a clear rule. Others need a conversation.

A standard payment schedule can be inserted automatically. A discount outside the agreed range needs approval. A request involving an unfamiliar market may need a delivery lead to investigate before anyone offers a fixed scope.

The system should make those decisions easy to find.

For example, a proposal draft might flag that the client expects results within a month but has not provided access to its advertising accounts. That gives the account director a concrete issue to resolve before agreeing to a timeline.

Leaving a question open is preferable to hiding it inside vague wording that both parties interpret differently.

Give AI the parts it can usefully assist with

AI could help turn call notes into a structured brief, identify missing information and draft a clear explanation of the proposed work.

Approved commercial information should come from its designated source. The proposal should show when a recommendation still needs review.

Anthropic’s guidance on building effective agents recommends starting with the simplest workable solution and increasing complexity when needed. For this agency, a workflow that prepares a reliable draft may be enough for the first version.

There is no need to give it authority to price, approve and send proposals immediately.

The first question is whether it helps the team produce better proposals with less effort.

Test it against completed work

Before using the workflow on a live opportunity, run it against a few past briefs.

Choose examples with different complications: a straightforward engagement, a heavily revised proposal and a project that caused a scope disagreement.

Compare the output with what the team eventually agreed. Look for missing assumptions, unsupported commitments and recommendations that sound plausible but don’t fit the brief.

An old proposal is not automatically the correct answer. The exercise is useful because the people involved can explain what happened and where their judgement changed the outcome.

Then try the workflow on a small number of current opportunities, with a person reviewing every draft.

Measure the whole proposal process

Drafting time is only one part of the cost.

If a document takes ten minutes to generate and two hours to correct, the team needs to understand what is going wrong. Track the time spent reviewing it, the decisions still unresolved and the revisions requested by delivery.

After proposals are sent, look at whether clients understand the scope and whether the work sold matches what the team starts delivering.

A faster proposal can be valuable. A clearer proposal can also prevent weeks of disagreement later.

Those are different benefits, and it helps to measure them separately.

Choose a first project the team can own

The same approach applies beyond proposals. An agency might begin with account research, campaign reporting or the handover from sales to delivery.

Choose a recurring task with accessible inputs and a clear owner. Write down what must be true before the system acts. Test the result with the people who will rely on it.

If the workflow exposes an unresolved question about pricing, scope or responsibility, work through that question. It is part of the project.

At OLN Labs, our product and GTM services help businesses turn these decisions into working systems. Bring us a process that keeps pulling your team away from clients. We can help scope a useful first change.