Back to Go2 AI Workflow Discovery Pilot
Operator Mode Discovery

Proposal Ops Coordinator

Maya Hart is an alias used for this public example. Underneath the sanitization, the telemetry is real: a 14-day pilot window showing a proposal-heavy role spending significant time turning loose inputs into customer-safe output across email, spreadsheets, product files, decks, PDFs, Slack, and outbound follow-up.

Window: 2026-03-12 to 2026-03-25
10 worked days / 12 sessions
2 late-window sync-gap days
Windows machine with keystroke capture

What a similar operator should expect

If your job looks like this one, the value is not the report by itself. The value is that you leave with one working tool, one real connector, and a plain-English install path you can paste into Codex or Claude Code without learning the plumbing first.

80.40
Session Hours
66.33
Active Hours Logged
23,350
App / Web Events
17-24
Recoverable Hrs / Week
1,316
Copy Events
1,525
Paste Events
67.8%
Micro Event Share
3,787
Keystroke Bins
How the savings estimate was derived: the six findings sum to roughly 19.5-27.5 hours of possible weekly relief if each workflow is solved in isolation. The headline 17-24 hours applies an overlap discount because several findings share the same browser, email, and file-browsing surfaces. Low assumes first-pass drafting and lookup removal only. High assumes lookup, routing, and approval-queue support all land with human review still in place.

Scope

This example was built from Cowork.ai app and web telemetry, session data, keystrokes, and the actual surface titles visible during the window. Names, employer, and identifying document details were changed for public use, but the numbers and work shape were kept intact.

Strength

Customer-safe output

Proposal, catalog, and rebuttal work stays polished even when the source material is fragmented.

Pressure

Revenue-adjacent role

When a bid or response lags, the business feels it even if the work looks like admin on the surface.

Best fit

Messy-input operator

This pattern shows up when one person keeps turning inbox noise, pricing questions, and scattered files into customer-safe packets.

What You Keep After The Pilot

A similar operator should be able to leave with one working relief valve, one real connector starter, and a Monday install order that makes the first useful result obvious.

What ships: one working browser tool plus one real connector starter that proves AI can write back into inbox and CRM workflows.
If your job looks similar: paste the install prompt in Start Here into Codex or Claude Code and let it wire the starter pieces together around your inbox, CRM, and pricing source.
What stays human: final pricing judgment, final send, and anything that deserves approval instead of blind automation.
If the first writeback fails: reply in the thread with the error and we QA the install with you instead of leaving you alone with docs.

Revenue Pressure Map

The role is clearly revenue-adjacent, but most of the time is not spent in live selling. It is spent assembling the material that supports selling. That makes automation leverage unusually high because every hour removed from prep can either speed response or tighten quality control.

Email / calendar handling
16.06h
Proposal + deck surfaces
10.81h
Pricing sheets + calculator
8.23h
Slack coordination
7.50h
Live conversations
2.66h
Value-creation read: only 2.66 hours of the window showed up as live conversations while 16.06 hours were spent in email and calendar surfaces. In this role, speed-to-follow-up and speed-to-packet are likely the real revenue lever.

Primary Workflow Bottleneck

The sharpest read from this window is simple: the same proposal context is being re-entered across email, sheets, PDFs, decks, and Slack because there is no shared intake object or reusable response pack.

Repeated failure pattern observed

Pricing logic, asset retrieval, promise tracking, and customer-safe language all exist, but they live in scattered surfaces. The operator is spending focused time doing the right work in the wrong order: first rebuilding context, then producing output, then fixing the tracking layer afterward.

Day Pattern

Sessions show a full 10-day work pattern. Granular event capture is complete on 8 of those days, then drops out late in the window. The missing app stream is treated as a confidence note, not airbrushed away.

Mar 12
Session
8.00h
Active
8.01h
Mar 13
Session
8.05h
Active
7.89h
Mar 16
Session
8.08h
Active
8.03h
Mar 17
Session
8.28h
Active
8.11h
Mar 18
Session
8.50h
Active
8.53h
Mar 19
Session
8.71h
Active
8.75h
Mar 20
Session
8.72h
Active
8.77h
Mar 23
Session
8.17h
Active
8.23h
Mar 24
Session
8.88h
Active
sync gap
Mar 25
Session
5.01h
Active
sync gap

Key Findings

These findings are framed around configuration, workflow support, and missing operating layers. The operator is already carrying a lot of complexity well. The stack is making the job more manual than it needs to be.

Finding 01

Bid packs are still assembled, not generated

5.0-6.5h Recoverable / week

Proposal work shows up across PowerPoint, Word, Acrobat, Google Chrome, and Microsoft Edge instead of flowing from a single reusable brief. The role is doing real commercial synthesis, but starting too close to blank each time.

10.81 hours in proposal surfaces during the window
RFP deck, rebuttals, product catalog PDF, and proposal titles all show up as separate work islands
Deck and document surfaces are used on only part of the week, which suggests bursty deadline-driven prep
Install this: Proposal Intake Brief with Graph mail intake, pricing prefill, and a required-asset checklist.
Do this Monday: pick one high-volume request type, define required fields, and stop accepting “just handle this” as the intake format.
What breaks if you don’t: every new packet starts too close to blank, and senior operator time keeps getting burned on first-pass assembly work.
Expected result in 7 days: time-to-first-internal-brief drops materially and packet drafts stop missing obvious fields.
Finding 02

Browser-to-browser copy movement is carrying the workflow

4.0-5.5h Recoverable / week

The strongest automation signal here is not app time alone. It is the amount of context being pushed manually between surfaces. That is what happens when the operator knows what should happen next, but the system does not.

1,316 copies and 1,525 pastes across 3,787 keystroke bins
965 Google Chrome -> Microsoft Edge transitions and 653 Edge -> Chrome transitions, excluding Explorer
Chrome carried 990 copy events while Edge absorbed 730 paste events
Install this: a bridge that preloads account, pricing, and latest approved language into the destination surface before the operator starts copying.
Do this Monday: identify the single most repeated Chrome -> Edge transfer and automate that one before touching anything else.
What breaks if you don’t: the operator stays the human integration layer and every browser switch keeps multiplying friction.
Expected result in 7 days: fewer cross-browser jumps and a visible drop in raw copy-paste pressure on heavy packet days.
Finding 03

Follow-up work is taking more room than live selling

3.0-4.5h Recoverable / week

For a revenue-adjacent operator, that usually means the system is weak at promise tracking and next-step drafting. The work is happening. The closure layer is not.

16.06 hours in email / calendar surfaces versus 2.66 hours in live-conversation surfaces
Mail, inbox, and calendar views dominate multiple days in the window
The role clearly supports selling, but the time mix suggests a manual async handoff problem
Install this: the Outlook -> CRM bridge first, then a promise-lag sentry on top of it.
Do this Monday: sync the last 10 sent follow-ups into the CRM and inspect where the relay is currently failing.
What breaks if you don’t: good outbound work remains invisible to the pipeline, and follow-up discipline depends on human memory instead of system support.
Expected result in 7 days: every outbound follow-up touching an active opportunity creates a note or activity unless explicitly skipped.
Finding 04

Slack is interrupting exactly where proposal work needs calm

2.0-3.0h Recoverable / week

This is not a communication problem. It is a routing problem. Approvals, clarifications, and side-channel requests are landing in the same lane where proposal quality depends on uninterrupted concentration.

7.50 hours in Slack during the window
March 17 showed 3.13 Slack hours on a day that also carried 2.37 proposal hours
504 Slack -> Edge transitions and 372 Edge -> Slack transitions, excluding Explorer
Install this: Slack approval digest with timed review windows and escalation only for true blockers.
Do this Monday: define which requests are true blockers and which ones can wait for the next digest window.
What breaks if you don’t: proposal mode keeps getting shattered by side-channel asks that feel urgent but do not deserve real-time interruption.
Expected result in 7 days: fewer mid-packet interruptions without a measurable drop in response quality or turnaround.
Finding 05

Pricing logic still lives in sheets and calculator muscle memory

3.0-4.0h Recoverable / week

The operator is clearly trusted to translate pricing into customer-safe output, but the current setup still leans on sheet time, point lookups, and lightweight math instead of a guarded quote layer.

8.23 hours tied to Google Sheets titles and calculator usage
The primary pricing sheet alone accounted for 6.20 hours
Calculator showed activity on 7 instrumented days and 40 Enter events in keystroke capture
Install this: pricing-sheet guardrail that validates rows, flags low-confidence outputs, and drafts quote-safe copy.
Do this Monday: choose one pricing sheet and one quote pattern, then lock the validation rules for that path before expanding.
What breaks if you don’t: pricing trust stays buried in operator muscle memory and every quote still requires point-by-point verification.
Expected result in 7 days: calculator use drops and pricing review starts happening inside one guarded path instead of across scattered surfaces.
Finding 06

Asset retrieval is still file-system work instead of intent-driven retrieval

2.5-4.0h Recoverable / week

Proposal quality depends on version trust. Right now the operator spends visible time getting to the right file before doing the real judgment work. That is exactly where a small memory / resolver layer earns its keep.

4,469 Windows Explorer -> Chrome transitions and 4,121 Chrome -> Explorer transitions
Acrobat, PowerPoint, Word, and Chrome repeatedly touch the same proposal lane
Catalog PDFs and rebuttal files are active evidence surfaces, not just archival files
Install this: quote asset resolver keyed on account, product family, and bid id.
Do this Monday: define the canonical folder or source for deck shell, catalog slice, and rebuttal pack, then make retrieval queryable.
What breaks if you don’t: version trust remains a scavenger hunt and operators keep wasting time proving they have the right file before they can do judgment work.
Expected result in 7 days: operators can fetch the current deck shell, catalog slice, and rebuttal pack without Explorer browsing.

Fix Order

Do not automate everything at once. Install in this order so each layer removes visible pain before the next one lands. The goal is to stop spending skilled time on context transfer, asset hunting, and promise cleanup.

1

Proposal Intake Brief

Trigger on a forwarded RFP, customer request, or new pricing ask. Normalize the request, pull the right sheet rows and catalog references, and open one internal brief with the missing-data checklist already attached.

Reads: inbox
Pulls: Sheets + Drive
Queues: Slack approval
5.0-7.0h / week
2

Quote Asset Resolver

Use the customer name, product family, or bid ID as the lookup key and fetch the right catalog excerpt, latest pricing logic, last approved rebuttals, and current deck shell without relying on file browsing or browser tab archaeology.

Searches: Drive / SharePoint
Checks: Sheets
Links: CRM records
4.0-5.0h / week
3

Promise Lag Sentry

Watch sent mail, calendar, and call surfaces for live promises. If a reply deadline is getting old or an intro call happened without a logged next step, generate the follow-up and queue the operator for approval instead of hoping memory holds it.

Watches: sent mail + calendar
Reads: call logs
Queues: Slack alerts
3.0-4.5h / week
4

Outlook -> CRM Bridge

This one is already shipped in the example folder. It reads recent Outlook follow-ups, matches recipients to CRM people, and writes the email context back into the pipeline so the operator is no longer the relay layer.

Reads: Outlook sent mail
Writes: CRM notes + tasks
Runs: same day
2.5-4.0h / week
5

Slack Approval Digest

Bundle interruptions into timed review windows. The operator still gets the answers and approvals they need, but the request stream stops breaking proposal-building mode every few minutes.

Batches: Slack approvals
Checks: calendar windows
Routes: task board
2.0-3.0h / week

Start Here

This needs to work for a non-technical operator and still show the power path. So there are three ways in: use the tool yourself right now, hand the setup note to an admin, or go full power and wire the live systems together.

Use it yourself in 5 minutes

If you can copy and paste, you can use the browser tool today without touching setup.

  • Open the tool
  • Paste one messy request email
  • Generate the internal brief, customer reply, and team handoff
This is the zero-technical path. It gives the operator relief before any live systems are connected.

Send this to your admin

If someone else handles setup, hand them one short note instead of making the operator learn the tooling.

  • Open the admin handoff note
  • They connect Outlook and the CRM once
  • You test one real follow-up writeback
This is the easiest realistic install path for a non-technical team.

Go full power

Once the live connectors are in, the system stops being a drafting aid and starts behaving like an operating layer.

  • Inbox requests become structured intake
  • Follow-ups write back into the CRM automatically
  • Pricing, approvals, and missing assets get queued instead of lost
This is the strongest version of the offer: not just better output, but a better operating system for the role.

If your job looks like this

You gather messy requests from email, pricing sheets, product files, and Slack, then turn them into a clean packet, a customer-safe follow-up, and a tracked next step.

Best fit: proposal ops, sales ops, recruiting ops, marketplace ops, and founder follow-up roles with heavy inbox-to-pipeline work.
Game-changer test: if one clean intake object and automatic writeback would remove visible copy-paste and follow-up debt from your week, this should land fast.
Originally built for: a real operator in a similar role shape, then stripped of names, company details, and customer identifiers for public use.
One working tool before you decide anything. If the connector does not write back cleanly on the first run, the install failed, not you.

Do this Monday

Keep it simple. The point is to remove one live leak, not to build the whole future state on day one.

Your admin does once: add the Outlook and CRM credentials to the connector starter.
The operator types next: paste the install prompt into Codex or Claude Code and let it handle the wiring.
What success looks like: one synced CRM note, one follow-up task, and one unmatched-email review list from a real test run.
If it breaks: reply in the thread with the exact error and we QA the install with you.

Paste This Into Codex Or Claude Code

Operator-facing install move. Use this when the person doing the work wants the assistant to wire the starter pieces together without learning setup vocabulary first.

Install the starter stack from this proposal-ops discovery example.

Use these assets:
- Browser tool: ./proposal-response-pack-builder.html
- Connector starter: https://github.com/Scottpedia0/outlook-pipedrive-mcp
- Connector sample output: ./outlook-pipedrive-mcp/sample-sync-output.json

What to do:
1. Install the Outlook -> CRM connector starter and generate the right local paste-in setup block for this machine.
2. Ask only for the credentials or field mappings you truly need.
3. Create these three starter workflows around the operator's real tools:
   - proposal_intake_brief
   - promise_lag_sentry
   - pricing_sheet_guardrail
4. Make one raw inbound request produce:
   - an internal brief
   - a customer-safe reply draft
   - a Slack or CRM handoff
5. Keep human approval on pricing, scope, and send.
6. Run one real inbox -> CRM writeback test.
7. If writeback fails, show the exact failing step, the exact error, and the smallest next fix.

Output:
- installed paste-in setup block
- env var checklist
- missing field mappings, if any
- first successful test run or exact blocker
- the next Monday test the operator should run

Do not explain the plumbing unless asked. Prefer a working install over a long explanation.

Send This To Your Admin Or IT

Non-technical handoff. If the operator should not touch setup, copy this note and send it to the person who handles systems.

Please set up the starter stack from this Go2 x Cowork.ai proposal-ops discovery example for the operator on this machine.

Use these assets:
- Browser tool: ./proposal-response-pack-builder.html
- Connector starter: https://github.com/Scottpedia0/outlook-pipedrive-mcp
- Admin install note: ./proposal-ops-send-to-admin.md

What I need from you:
1. Connect Outlook and the CRM to the connector starter.
2. Generate the local setup block for Codex or Claude Code.
3. Ask me only for the credentials or field mappings you actually need.
4. Run one real test that logs a sent follow-up into the CRM.
5. Leave me with:
   - one working setup block
   - one successful test result or exact blocker
   - the one next thing I should test on Monday

Goal:
The operator should not have to learn the tooling. They should be able to copy a messy request into the tool, get a clean output, and have follow-ups start writing back into the CRM.

Proposal Intake Brief

Use this when the role keeps getting “just handle this” requests with missing scope, assets, or due dates.

{
  "name": "proposal_intake_brief",
  "trigger": "new bid request or forwarded RFP email",
  "skills": [
    "request_normalizer",
    "quote_pack_drafter",
    "followup_composer"
  ],
  "mcps": [
    "microsoft_graph",
    "google_drive",
    "google_sheets",
    "slack"
  ],
  "steps": [
    "extract account, bid id, due date, scope, and missing inputs",
    "pull the current pricing rows and latest approved catalog assets",
    "draft one internal brief with a missing-data checklist",
    "draft the external acknowledgement email",
    "post the approval card to Slack"
  ]
}

Promise Lag Sentry

Use this when follow-up quality depends too much on human memory after the meeting or sent email already happened.

{
  "name": "promise_lag_sentry",
  "trigger": "every 30 minutes during local working hours",
  "inputs": [
    "outlook_sent_items",
    "calendar_events",
    "dialpad_calls",
    "proposal_tracker_sheet"
  ],
  "rules": [
    "if a customer promise is older than 4 business hours and no reply exists, draft the follow-up",
    "if a bid due date is within 24 hours and a deck or catalog asset is still missing, escalate to Slack",
    "if an intro call happened and no summary exists, generate one and queue it for approval"
  ],
  "outputs": [
    "customer-safe email draft",
    "internal next-step card",
    "risk escalation note"
  ]
}

Pricing Guardrail

Use this when sheet logic, lightweight calculator work, and quote-safe language still live in operator muscle memory.

{
  "name": "pricing_sheet_guardrail",
  "trigger": "sheet row update or new product bundle request",
  "skills": [
    "sku_resolver",
    "margin_checker",
    "quote_writer"
  ],
  "mcps": [
    "google_sheets",
    "catalog_source",
    "slack"
  ],
  "outputs": [
    "validated price block",
    "margin warning if thresholds are crossed",
    "customer-safe quote text",
    "approval card when confidence is low"
  ]
}

Paste This Setup Block

Paste this into Codex or Claude Code after you have credentials. It tells the agent how to connect Outlook and the CRM.

{
  "mcpServers": {
    "outlook-pipedrive": {
      "command": "node",
      "args": [
        "/absolute/path/to/outlook-pipedrive-mcp/server.mjs"
      ],
      "env": {
        "GRAPH_TENANT_ID": "your-tenant-id",
        "GRAPH_CLIENT_ID": "your-client-id",
        "GRAPH_CLIENT_SECRET": "your-client-secret",
        "GRAPH_USER_ID": "[email protected]",
        "PIPEDRIVE_API_TOKEN": "your-pipedrive-api-token",
        "PIPEDRIVE_BASE_URL": "https://api.pipedrive.com"
      }
    }
  }
}

Hooks

These are the first working hooks a similar operator could use right away. In starter mode they remove blank-page work. In full-power mode they become a role-specific operating layer across inbox, CRM, pricing, and approvals.

Included tool

Proposal Response Pack Builder

A browser-based first-pass drafting tool that converts raw request text or manual context into three reusable outputs. If a similar operator opened this today, they could stop starting proposals from a blank page before the live connectors are even wired.

  • Generates an internal brief from rough notes, assets, and risks
  • Drafts the customer-safe follow-up automatically
  • Creates a Slack-ready handoff so work does not die in personal memory
Included connector

Outlook -> CRM Bridge

A real starter connector that reads sent Outlook follow-up context and writes it back into the CRM as notes and next-step activities. It is intentionally narrow so a buyer can feel real writeback value without handing over the dangerous parts first.

  • Lists recent sent Outlook messages through Microsoft Graph
  • Matches people in Pipedrive by recipient email
  • Writes synced notes and follow-up activities back into the CRM
Full-power unlock: once this is live, follow-up logging stops depending on memory and starts happening as part of the workflow itself.

Evidence

The findings above are backed by counted surfaces, visible document titles, and observed handoff patterns from the actual two-week window.

Top Surfaces

Surface Hours Events Active Days Supports
Google Chrome26.476,48181, 2, 3, 6
Microsoft Edge17.364,00382, 3, 4
Slack7.501,41584
Microsoft PowerPoint3.2422631, 6
Adobe Acrobat2.8828381, 6
Windows Explorer2.699,69886
Microsoft Word1.6713031, 6
Calculator1.164875

Document / Title Receipts

Title Hours Supports
Primary pricing sheet - Google Sheets6.205
Mail - Outlook surfaces3.98+3
Enterprise RFP deck - PowerPoint2.831
Current product catalog PDF1.101, 6
Rebuttals - Word0.961, 6
Industrial project bid draft0.861
Meet - intro call0.453
Dialpad0.423

Clipboard Pressure By Day

Day Bins Copies Pastes Corrections
Mar 12244293773
Mar 13761111
Mar 16200202270
Mar 17189213857
Mar 18508228262177
Mar 19992359515251
Mar 20921373374232
Mar 23657285276116

Non-Explorer Transition Hotspots

From To Count
Google ChromeMicrosoft Edge965
Microsoft EdgeGoogle Chrome653
SlackMicrosoft Edge504
Microsoft EdgeSlack372
Google ChromeSlack153
SlackGoogle Chrome131
Google ChromeMicrosoft PowerPoint57
Microsoft PowerPointGoogle Chrome38

Notes

This report is role-shaped on purpose. A customer support worker, bookkeeper, or founder would get a very different read because the pressure surfaces and the missing automations would be different.

Anonymization

Alias, company identity, and identifying document details were changed. The timing, counts, and behavioral structure were preserved for a public-safe example.

Confidence note

Session data captured 10 worked days and 12 sessions. Granular app/web capture populated fully for 8 days in the window. That is why session hours and active hours do not line up one-to-one.