Morgan Chen

December planning made the September board stance real for Q1. HR asked whether Evergreen’s paid pilot plus Nadia’s cleaner account conversations are enough to open RevOps, CS, SDR, field-sales, or the second Mercury engineering req in early 2025. Devon and I are keeping it lightweight: Nadia’s individual weekly read, with Sarah continuing account-note input hygiene. No Q1 openings for those lanes. We’ll revisit team shape only after the January Evergreen renewal/pilot evidence, materially repeatable account-source quality, owner-routed enterprise-readiness intake, and shipped enterprise-readiness adoption. Also keeping the Mercury roadmap line intact: one enterprise account’s conversations are not enough to justify bespoke roadmap commitments.

The Atlas webhook-delivery question from support is closed. Support kept the customer owner named, Leo did the first technical read and found a stale receiver config, the customer confirmed the fix, and Jake isn’t moving Atlas sequencing because of it. This stayed inside the post-Rishi split — no new owner or routing rule.

Evergreen’s December pilot read is stronger than October, still not a blank check. They validated SAML login, admin-audit lookup for the visible invite/source/admin changes, and the workspace-admin support path. Devon, Sarah, Nadia, Jake, and Leo now have a current-state packet Evergreen can circulate internally: shipped SAML SSO, that visible audit event set, the workspace-admin support path, certificate-rotation operational contacts, and monthly-active-developer usage. I’m labeling this as pilot current-state material only. The broader procurement/security packet and advanced-admin controls stay on their own track.

Kara sent Kestrel’s first post-update Mercury page snapshot. Directionally fine: modest traffic, better scroll depth on the admin-role section, and the only external referrer they called out is the generic product newsletter. It’s a slide snapshot, not raw analytics, and Sarah hasn’t checked it against our dashboard yet.

Can you review HR’s year-end office note and suggest wording changes? The draft is using “company shutdown,” but the support calendar still has customer-impacting coverage during that week. I want the note to make the office break clear without implying Scaffold is fully shut down. Subject: Company shutdown: year-end office schedule and reminders Hi team, As we head into the end of the year, a reminder that Scaffold will be on a company shutdown from Tuesday, December 24 through Wednesday, January 1. The office will be closed during that period, and we want everyone to use the time to fully unplug and recharge. A few expectations for the shutdown window: - Monday, December 23 is the last regular workday before the break. - We are treating this as a full company shutdown, so there should be no meetings, routine requests, or normal cross-functional handoffs during that time. - Please do not expect responses to email or messages until everyone is back on Thursday, January 2. - If you have work that needs review or a decision before the break, please bring it to your manager this week. - If you are planning to extend your time away before or after the shutdown, please make sure it is recorded and coordinated with your manager. Before you head out, please take care of the following: - Set your out-of-office message before the end of day on December 23. - Decline or move any meetings that fall during the shutdown window. - Submit outstanding expense reimbursements and any payroll-related corrections by Friday, December 20. - Take home any equipment you may need after the break. - Clean out food from the fridge and leave shared spaces in good order. For planning purposes, normal business operations resume on Thursday, January 2. If something truly urgent comes up during the shutdown, managers should use their judgment and escalate through the leadership chain only if necessary. Thanks everyone for all the work this year, and happy holidays. HR

Small Acme thing is closed: Greg asked Sarah why an API v2 export CSV came back in a different row order than the dashboard preview. Leo found it was just a sort-parameter mismatch in Acme’s request, and Greg confirmed the corrected request returns the order they expected.

Evergreen is extending the paid Mercury Growth pilot through January 31, 2025 while procurement finishes their internal review. Devon kept it on the same standard Growth band from the October 1 pilot: $7,500/month including up to 200 monthly active developers, then $1,000 per additional 50 monthly active developers. No Evergreen-specific roadmap carveout. SAML SSO and admin-audit validation stay included for the January extension, and any annual deal or enterprise add-on pricing is still a separate quote after they finish reviewing the current-state packet.

First heavy Oakland rain after the holiday grocery run found us a small living-room window leak. Jamie put a towel down, Kibo kept trying to investigate, and I filed the maintenance ticket with photos. Portal has receipt but no appointment time yet.

Devon needs a one-paragraph variance explanation before the year-end AP packet closes. This raw dashboard screenshot is all I have so far; can you turn it into something concise and finance-readable? Cloud infrastructure dashboard — screenshot transcription Captured: 2024-12-23 View: Monthly spend / actuals + forecast Header card - Cloud infrastructure spend - Current month status: Forecast - December 2024 forecast: $9,184.37 - Threshold note: First month in this series forecast above $9,000 Monthly series | Month | Amount | Status | | Sep 2024 | $8,642.18 | Actual | | Oct 2024 | $8,920.00 | Actual | | Dec 2024 | $9,184.37 | Forecast | Visible trend note - Up from September to October - December forecast above October by $264.37 - December forecast above September by $542.19 Usage drivers panel Top drivers called out for December forecast: 1. Production API v2 traffic 2. Two large customer backfills Driver detail text visible in the screenshot - Most of the December increase is attributed to higher production API v2 traffic. - Two large customer backfills are also contributing to the higher December forecast. Chart labels visible - Series: monthly cloud infrastructure spend - Latest point: Dec forecast $9,184.37 - Prior labeled points: Sep $8,642.18; Oct $8,920.00

Christmas Eve morning stayed local and quiet: Jamie and I did a short flat Lake Merritt walk with Kibo, grabbed coffee, and got home before everything turned crowded. His gait looked normal enough on the shorter route, and I kept the household block offline.

Can you tighten Devon’s year-end note into something HR can format as-is? I want it to still feel like a team thank-you, not a board memo, and the metric bullets should come through as lighter year-end language instead of three dense blocks. Subject: Year-end team note draft From: Devon Hayes To: Morgan Chen - Team — - As we wrap 2024, we keep coming back to how much hard, unglamorous work it took to turn enterprise learning into product that is clearer, more repeatable, and easier for customers to trust on day one. - We made real progress on the parts of Scaffold that decide whether a customer gets set up quickly, gets their first source connected, sees a live sync, invites teammates, and feels like the product can support a serious deployment. - Project Mercury pulled a lot of that into focus, but this was not just one project or one team. Engineering, product, design, support, and everyone carrying customer context helped reduce one-off setup work and turn it into something we can ship repeatedly. - Atlas also got stronger in the ways that matter most once customers are live: better auth and verification paths, more usable webhook and connector behavior, clearer docs, faster first technical reads, and less thrash on issues that used to bounce around. - The numbers behind that progress are meaningful: median time from workspace creation to first connected source moved from 2.4 days in Q1 to 0.9 days in Q4; the share of new workspaces reaching a first live sync within 14 days rose from 41% to 63%; teammate invitations on activated workspaces increased from 28% to 47%. - In the core Mercury setup flow, workspace creation success improved from 93.8% to 97.9%; first-source connection completion moved from 54% to 72%; and first successful sync on connected workspaces increased from 68% to 84%. - Enterprise-readiness and repeatability improved together: admin-role setup on new enterprise workspaces rose from 61% to 88%; median time to close high-priority Atlas issues dropped from 2.6 business days to 0.9; and the auth / webhook / connector docs refresh deflected 37% of repeat enterprise implementation questions in the second half. - More important than any single metric, people kept showing up for each other while we were changing the product under real customer pressure. That takes judgment, patience, and a lot of follow-through that rarely gets enough credit. - Thank you for sticking with the hard parts, for caring about the details customers actually feel, and for helping build a company that learns and gets better instead of just getting louder. - We’re proud of what this team shipped this year, and we’re excited for what we can build from here.

I need to make the AP call before 4. Can you read this hold packet and recommend approve/defer for each line, with the rationale tight enough that I can send the dispositions back separately? Subject: Final year-end vendor holds - approval or defer before close From: AP To: Morgan Chen Date: 2024-12-30 Morgan, Below is the final vendor-hold packet for 2024 close. Please mark APPROVE or DEFER on each line by 4:00 PM PT on 12/30. Reminder: any invoice/payment over $5,000 stays on manual review before payment. Final hold summary - Items requiring disposition: 3 - Gross amount if all three are approved as submitted: $7,034.37 - Items over $5,000 requiring manual review before payment: 1 - Estimate/accrual items with no vendor invoice attached: 2 1) Hold ID: VH-2024-12-041 Vendor / item: Kestrel Marketing - December maintenance-copy invoice Document reference: KEST-2024-12-MAINT Amount: $6,000.00 Type: Vendor invoice Service period: 12/01/2024-12/31/2024 Hold reason: Year-end vendor hold pending executive disposition; payment also remains on manual review because amount exceeds $5,000. AP notes: Matches the approved monthly maintenance-copy line with no variance. Scope on invoice is maintenance copy only (landing-page updates, lifecycle copy maintenance, and routine copy QA). Invoice was received 12/27. No additional December Kestrel charges are in queue. If approved: Book to December vendor expense and release to the first January payment run after manual review. If deferred: Keep on vendor hold and do not release for payment through this close. Requested disposition: APPROVE or DEFER 2) Hold ID: VH-2024-12-042 Vendor / item: Cloud infrastructure - December overage estimate above committed monthly baseline Document reference: Close estimate only; vendor bill not yet received Amount: $184.37 estimated overage Type: Accrual estimate Hold reason: Estimate-only close item pending executive disposition. AP notes: Current December cloud infrastructure forecast remains $9,184.37 total. Committed monthly baseline is $9,000.00, leaving an estimated overage of $184.37. Estimate was prepared from the 12/29 usage snapshot. No payment can be released until the vendor invoice is received; January actuals may true up above or below this estimate. If approved: Accrue the $184.37 overage to December and true up when the actual invoice lands. If deferred: Do not accrue the estimated overage in December; book against January actuals only. Requested disposition: APPROVE or DEFER 3) Hold ID: VH-2024-12-043 Vendor / item: Outside counsel - duplicate legal-retainer accrual Document reference: Duplicate accrual entry tied to December retainer support Amount: $850.00 Type: Accrual cleanup Hold reason: Potential duplicate identified during final close review. AP notes: A December legal retainer accrual is already booked from the counsel support packet. This line appears to be a second entry created from the same source support during re-import. No second invoice or separate retainer backup is attached. If approved: Keep the duplicate $850.00 accrual in December. If deferred: Remove/reverse the duplicate accrual before close. Requested disposition: APPROVE or DEFER If no response is received by close, AP will leave all three items on hold and exclude the two accrual items from the final 2024 close package until instructed otherwise.

Oakland maintenance offered a January 2 inspection for the window leak. Jamie can keep the towel setup in place until then, but I’m leaving the portal message open for now because their window cuts into my first Scaffold planning block of January.

I’m doing a 20-minute New Year’s reset, not a deck. Help me turn the first-week frame into five bullets I can use with Devon and Jake: Mercury activation first; Evergreen stays current-state/procurement and does not become a roadmap carve-out; Atlas customer issues stay in support/product routing instead of founder-direct; no new hiring lane off one customer signal; and keep Q1 planning narrow.

Please add the return repair window from this portal update to my calendar, with the practical Kibo and towel notes in the hold so it doesn’t get buried under first-week Scaffold planning. Oakland Resident Portal Maintenance Update Unit 3B — living-room window leak Posted after inspection: January 2, 2025 Inspection completed today. Finding: - Failed sealant around the lower living-room window frame. Repair plan: - The lower frame needs additional time to dry before resealing. - Maintenance will return to complete the reseal once the frame is dry enough. - Return window offered: January 6, 2025, 10:00 AM–12:00 PM Pacific. Resident instructions: - Please keep the towel setup in place until the repair is complete. - Please keep pets out of the living-room work area while sealant is being applied and during cure time. Ticket notes: - No rent charge is attached to this ticket. - No lease change is attached to this ticket. - No paid resident scope is attached to this ticket.

Please Slack Jake: “Maintenance is still in the apartment; start the Mercury block without me. Use the first 15 on workspace creation → first source → first live sync cutlines, and I’ll join at 10:15 PT. Don’t turn Evergreen asks into new scope while I’m offline.”

Can you turn my rough notes into a Slack-ready decision note for Jake, Leo, and Sarah? Keep it operational, not a Q1 strategy memo. The takeaway should be that January Mercury stays on setup activation and admin-role basics, and Evergreen input is useful only inside the shipped SAML/current-state lane, not as a reason to widen enterprise scope. Jan 2 Mercury planning block — rough notes Morgan + Jake Main cutline for January: - Mercury stays on setup/activation, not a widened enterprise pass. - Priority path remains: 1. workspace creation 2. first connected source 3. first live sync reliability 4. teammate invitations 5. admin-role basics Guardrails: - Keep admin-role work in the basics/clarity lane. - Do not let January work expand into broader enterprise-readiness scope. - Evergreen feedback is useful as validation and procurement input unless it maps directly to the shipped SAML SSO path or the visible current-state admin/audit support path. - If it does not map to those shipped/current-state lanes, it is not January Mercury scope. Ownership / routing: - Jake owns Mercury sequencing. - Pull Leo Park in for data/platform seams and release-discipline cases, not as a broad product owner. - Sarah Kim should keep customer-specific notes grounded in the actual account thread/current-state packet, not as loose product-scope drift. Explicit non-outcomes from this block: - No new sales ask. - No new customer-success ask. - No new enterprise-readiness hiring ask. - No hiring signal should be taken from a single January customer thread. Working shorthand: - activation first - shipped/current-state lane only for Evergreen-related input - do not widen January because procurement asks are noisier than product facts

Year-end AP is closed. Finance released Kestrel’s $6,000 December maintenance-copy invoice to the first January payment run after manual review, trued the December AWS/cloud overage accrual against the actual invoice with only a small adjustment, and reversed the duplicate legal-retainer accrual before locking the final 2024 close package. No change to the over-$5,000 manual-review rule and no new vendor policy.

Please write the reply Sarah can send with Devon cc’d. It should confirm the shipped/current-state pieces — SAML SSO, certificate-rotation operational contacts, the visible invite/source/admin audit lookup, and monthly-active-developer usage — but not promise advanced admin controls or the broader procurement/security questionnaire as part of the current baseline. Those stay separately scoped if there’s later work. Subject: Fwd: January procurement follow-up on Mercury Growth pilot packet From: Sarah Kim To: Morgan Chen Cc: Devon Hayes Date: January 3, 2025 Forwarding the first January procurement follow-up from Evergreen. My read is that this stays inside the current-state pilot packet only. The items around shipped SAML, certificate rotation contacts, the visible invite/source/admin audit lookup, and MAD usage definition are all in-bounds to confirm. The two places where this could get sloppy are advanced admin controls and the broader procurement/security questionnaire. Can you help me sharpen the response line before I send it back with Devon copied? --- From: Devon Hayes To: Morgan Chen Cc: Sarah Kim Date: January 3, 2025 Subject: Re: Fwd: January procurement follow-up on Mercury Growth pilot packet Agree with Sarah's read. The January extension is still on the standard Growth pilot terms. We should answer from the current-state packet and keep this out of any annual-baseline language or customer-specific roadmap carve-out. --- Forwarded message --- From: Evergreen Bank Procurement To: Sarah Kim Date: January 3, 2025 Subject: January follow-up on current pilot packet Hi Sarah, As part of our January procurement review, can you confirm whether the current pilot packet covers the following items in the existing Mercury Growth pilot baseline: 1) shipped SAML SSO support 2) certificate-rotation operational contacts 3) the visible audit lookup validated in December for invite, source, and admin changes 4) the monthly-active-developer usage definition used in the pilot We also want to clarify two related items: 5) whether advanced admin controls can be included in the same baseline 6) whether the broader procurement/security questionnaire can be completed as part of the current package Thanks, Evergreen Bank Procurement

Can you order one green curry from Lemongrass for tonight? Jamie and I are staying in and I do not want another decision.

Can you make me a short vet-question list for Friday’s Kibo recheck? I want to ask about the shorter flat Lake Merritt walks, how strict to stay on measured food/no-poultry treats, whether the joint supplement is still the right one, and what symptoms should make us come in sooner. Keep it easy to read from my phone.

Window leak ticket is closed. Maintenance came back after the lower frame dried, resealed it, Jamie kept the towel setup in place until they finished, and Kibo stayed out of the living-room work area while the sealant cured. Portal shows no rent adjustment, lease change, or paid tenant scope.

Give me a two-sentence reply I can paste: thanks, moving this through the support rotation; Leo will do the first technical read if it’s API, webhook, or auth-related; Jake owns whether anything changes product priority. Calm and clear, not a lecture.

Help me answer Kara warmly but firmly. Yes to maintenance updates around shipped Mercury setup, admin-role copy, and first-live-sync lifecycle language; no to “enterprise-ready admin controls” as a headline. The December snapshot is directional slide material unless Sarah validates it against our dashboard, so Kestrel should not cite it as proof. Subject: January Mercury maintenance queue + headline question From: Kara To: Morgan Chen Date: January 7, 2025 Hi Morgan, We are putting together a January maintenance-copy pass for Mercury and wanted to check the queue with you before we tighten anything. Current proposed updates: - refresh the Mercury admin-role section - clean up the first-source setup help text - add/tune a lifecycle-email line around the first live sync moment On the admin section specifically, can we sharpen the headline language to something like "enterprise-ready admin controls," or is that too far past the lane you want? My understanding is that we can maintain copy around the shipped Mercury setup/admin-role concepts, but we should not imply advanced admin controls are already available if they are not. Separate question on the December page snapshot we sent: can we cite that as evidence that the updated Mercury messaging improved activation, or should it still be treated as directional slide material unless Sarah Kim validates it against your dashboard? Happy to keep this pass narrow if that is the better boundary. Thanks, Kara Kestrel Marketing

Jake’s midweek Mercury check is basically: workspace creation is in decent shape, but the first-source, first-live-sync, teammate-invite, and admin-role cutlines still need sharper sequencing. Help me turn that into a Slack-ready update for Jake, Leo, and Sarah. The frame I want: January activation proof is workspace created → first source connected → first live sync working, with teammate invite/admin-role basics as the enterprise-readiness floor. Evergreen feedback can inform wording, but it should not pull in advanced-admin or SAML-adjacent expansion unless that scope is already shipped/current-state. Keep it short enough that Jake can use it in standup.

Can you draft the reply Sarah can send with Devon cc’d? I want clear yeses on the things we actually have: SAML SSO, certificate-rotation operational contacts, the visible invite/source/admin audit lookup, and monthly active developer usage. For custom admin controls and broader procurement/security packaging, say those are not part of the current baseline and would be separately scoped if the relevant work exists later. No defensive tone. Subject: Fwd: Follow-up on current Mercury pilot packet From: Sarah Kim To: Morgan Chen Cc: Devon Hayes Date: January 8, 2025 Forwarding the next Evergreen procurement pass. This still mostly reads like current-state Mercury / pilot-packet confirmation, but item 5 is trying to pull custom admin permission bundles into an annual baseline. I think we should answer the shipped items directly and keep the rest out of the current baseline. Devon, adding you here because I want the wording tight before I send anything back. --- From: Devon Hayes To: Morgan Chen Cc: Sarah Kim Date: January 8, 2025 Subject: Re: Fwd: Follow-up on current Mercury pilot packet Agree. We should answer only from shipped/current-state scope. Please don't imply annual-baseline coverage, roadmap commitments, or customer-specific pricing/packaging from this note. --- Forwarded message --- From: Evergreen Bank Procurement To: Sarah Kim Date: January 8, 2025 Subject: Follow-up on current Mercury pilot packet Hi Sarah, Thanks for the clarification on the current Mercury Growth pilot materials. As part of our January procurement review, can you please confirm whether the current pilot state covers the following items: 1) Is SAML SSO supported in the current Mercury pilot state? 2) What operational contact path should Evergreen use for future SAML certificate rotation? 3) Does the current visible audit lookup cover teammate invitations, connected sources, and admin-role changes? 4) Can monthly active developer usage be reported for procurement review under the pilot? We also want to clarify two related items as we review possible annual packaging: 5) Would custom admin permission bundles be included in an annual baseline? 6) Can the broader procurement/security questionnaire be treated as covered by the current-state packet? Thanks, Evergreen Bank Procurement

HR is asking whether the active Evergreen January thread means we should reopen a customer-growth, RevOps, or CS req, and Devon wants me to answer before it becomes a recruiting lane by default. Give me a short answer I can send to HR and Devon: don’t open a req off Evergreen alone. Nadia’s weekly customer-growth cadence plus Sarah’s account-thread hygiene is the operating model for now; if the January Mercury and Evergreen evidence turns into repeatable proof, we can revisit then instead of treating one account as the signal.

Can you text Jamie: “For Kibo’s recheck tomorrow, can you put the supplement bottle and measured-food scoop in the tote? I’ll bring the question list. Still no poultry treats even at the vet if they offer them.”

Please add Kibo’s April 11 routine senior-dog recheck to my calendar for 10:00–10:30 AM Pacific from the appointment card. Also keep the updated care plan straight for future sitter instructions or walk planning. Oakland vet Checkout summary Date: January 10, 2025 Patient: Kibo Visit type: Recheck Recheck notes: - Gait steady at today's visit. - Assessment remains mild senior-dog arthritis. - No acute injury assessment at this recheck. Continue current care plan: - Measured food. - Strict no-poultry care. - Vet-approved non-poultry joint supplement. - Shorter or flatter walks when stiff, including flatter Lake Merritt routes. Call sooner if any of the following recur before the next routine visit: - appetite changes - vomiting - gait problems Next routine senior-dog recheck: April 11, 2025 10:00 AM-10:30 AM Pacific --- Appointment card Kibo routine senior-dog recheck April 11, 2025 10:00 AM-10:30 AM Pacific Oakland vet Sooner visit if appetite, vomiting, or gait problems recur.

Can you order one green curry from Lemongrass for tonight? Jamie and I are staying in and I am out of decisions.

I want to keep this moving, but the boundaries still need to be explicit. Help me answer Kara warmly but firmly: keep the copy on shipped Mercury setup, teammate invites, admin-role basics, and first-live-sync lifecycle language. Remove “enterprise-ready admin controls” and “advanced role governance.” The December snapshot is directional slide material unless Sarah validates it against our dashboard, so they should not cite it as proof. Staging is fine only after the revised copy reflects that. Subject: Revised Mercury maintenance copy for January staging From: Kara To: Morgan Chen Date: January 13, 2025 Hi Morgan, We took another pass at the January Mercury maintenance copy and wanted to send the revised snippets before we move anything forward. Current proposed page copy Headline: “Enterprise-ready admin controls for every team.” Subhead: “Invite teammates, connect your first source, and watch first syncs live from day one.” Lifecycle email draft Proposed line in the setup / activation sequence: “Advanced role governance is available during setup.” Reasoning on the stronger admin language We used the December page snapshot as a proof point for the more assertive enterprise-readiness framing. The thought was that if the setup flow, teammate invites, and first-sync language were all reading more clearly, we could support a stronger admin headline at the same time. Question on staging If the above is directionally right, can this revised copy move to staging on January 15? Happy to keep tuning if you want us to pull the admin language back. Thanks, Kara Kestrel Marketing

Devon’s worksheet is below. Subject: Fwd: Evergreen procurement worksheet before Sarah's next follow-up From: Devon Hayes To: Morgan Chen Cc: Sarah Kim Date: January 14, 2025 Morgan — Sending the worksheet Evergreen is using plus my rough notes. It mixes current-state questions with annual-baseline / add-on language, so Sarah needs one answer posture before the next reply goes out. My read is still the same: answer the shipped/current-state items clearly and do not create a roadmap carve-out or pricing commitment. Pasted below. --- Evergreen procurement worksheet (working copy) 1. Current Mercury pilot state: SAML SSO Evergreen question: Please confirm whether SAML SSO is supported in the current Mercury pilot state. Rough note: This should be a straight current-state confirmation, not future-tense language. 2. Certificate rotation process / operational contacts Evergreen question: Please provide the process and operational contact path Evergreen should use for future SAML certificate rotation. Rough note: Okay to answer with operational contact path. Keep it operational; do not let it turn into a broader security-package answer. 3. Audit lookup coverage Evergreen question: Please confirm what the visible audit lookup currently covers for teammate invitations, connected sources, and admin changes. Rough note: This is the visible lookup already discussed. Keep it to invitations, connected sources, and admin-role/admin changes that are currently visible. 4. Monthly active developer usage Evergreen question: Please clarify how monthly active developer usage is counted and whether it can be reported for procurement review. Rough note: Use the pilot MAD definition. Fine to confirm it can be reported for review. 5. Annual baseline / admin controls Evergreen question: If Evergreen converts from pilot to annual, are custom admin-role policy and a granular role editor part of the annual baseline? Rough note: This is where the worksheet starts mixing in non-baseline scope. Do not imply this is included in an annual baseline. Also do not write it like a roadmap commitment. 6. Annual conversion / broader procurement-security add-ons Evergreen question: If Evergreen converts from pilot to annual, can broader procurement/security add-ons be treated as included in the package? Rough note: No blanket inclusion language here. If later work exists, it needs separate scope / packaging / quote. Not part of the current pilot packet. --- If it helps, I'd like Sarah to have one clean internal version that separates: - what we can say yes to now - what stays outside the current baseline Devon Turn it into a prep grid for Sarah and Devon: column one is the Evergreen question, column two is the safe current-state answer, column three is the boundary. The posture should be: yes on shipped SAML SSO, certificate-rotation contacts, visible invite/source/admin audit lookup, and monthly active developer usage; no implied annual baseline for custom admin-role policy, granular role editor, or broader procurement/security add-ons. Those stay separately scoped if the work exists later.

Sarah is ready to turn the Evergreen grid into the next customer reply, and Devon caught one sentence that still sounds like we’ve already defined an annual baseline. Can you rewrite Sarah’s note so she can send it with Devon cc’d? It should be a clear yes on what exists now: shipped SAML SSO, certificate-rotation operational contacts, visible invite/source/admin audit lookup, and monthly active developer usage. For custom admin-role policy, a granular role editor, and broader procurement/security packaging, say those are not in the current baseline and would be separately scoped if the relevant work exists later. Please strip anything that sounds like we’ve already agreed to an annual baseline.

Kara’s revision is below. I think this is finally inside the guardrails, but quick check: if you agree, give me a short ok-to-stage reply to Kara. Thank her for tightening it, say this version can go to staging, and keep the caveat that Sarah should validate any metric-like language before anything customer-facing. Subject: Re: Revised Mercury maintenance copy for January staging From: Kara To: Morgan Chen Date: January 15, 2025 Hi Morgan, Thanks for the clear guardrails on this. We tightened the January Mercury maintenance copy accordingly and pulled the admin language back. Updated proposed page copy Hero line: “Get from workspace to first live sync faster.” Admin section copy: “Use teammate invitations and basic admin roles to keep setup controlled.” Lifecycle email draft Updated line in the setup / activation sequence: “After your first source connects, confirm the first live sync and invite the teammates who need access.” Notes on the revision - Removed “enterprise-ready admin controls.” - Removed “advanced role governance.” - The December snapshot is now referenced only as an internal directional read and is not cited as customer proof. - We did not add any SSO, advanced-admin, or roadmap language. If this is now inside the line you want, we can move the maintenance-copy update to staging once you approve. Thanks, Kara Kestrel Marketing

Jake’s standup turned up two teammate-invite/admin-role edge cases, and I want to keep the line clean before this becomes Evergreen-shaped scope creep. Help me turn this into a short Slack update for Jake and Leo, with Sarah looped if customer wording changes: January Mercury acceptance is still workspace created → first source connected → first live sync, with teammate invite/admin-role basics as the enterprise-readiness floor. If the invite/admin edge cases affect that activation path, keep them in the cut. If they imply custom admin policy or broader role governance because Evergreen asked, defer and bring it back for separate scope.

These are my kickoff notes for Project Compass, the Scaffold product/operating project to make our internal customer-health signals useful in customer-facing and customer-growth work. Please turn them into a tight internal owner-routing note so the team understands Compass without reading it as a new hiring lane or another board-dashboard project. Project Compass kickoff notes Date: January 17, 2025 Participants: Morgan Chen, Anna Martinez, Nadia Singh, Jake, Leo Park, Sarah Kim Purpose of the meeting - Name the next operating/product push before the January work turns into separate account threads, Mercury cleanup, and board shorthand. - Use the signals Scaffold already has from internal operating work, but make them useful to customers and customer-growth follow-up instead of turning them into another internal reporting layer. Working project name - Project Compass Why now - We already have real signal categories showing up in Mercury/Evergreen work. - The current-state Evergreen packet exists, so enterprise-readiness can be handled as actual evidence instead of vague sales language. - The team does not want another board dashboard that looks clean internally but does not change what happens in an account. Project intent - Turn internal customer-health signals into customer-facing and customer-success/customer-growth follow-up that changes account behavior. - The point is not to score accounts for internal consumption only. - The point is to make the signal lead to a next action, better follow-up, or better customer-facing guidance. Signals currently available from internal operating use - Retention - Activation - Expansion - Admin friction - Enterprise readiness - Account-note quality Boundary / what Compass is not - Do not build another board dashboard. - Do not treat the first version as investor packaging. - Do not turn this into a generic health-score project. - Do not let it become a bespoke Evergreen side track. - Do not use Compass as a reason to open a new hiring lane. - Stay with the current lightweight staffing model. Discussion notes Morgan - The framing should stay operational and customer-real, not presentation-ready. - If Compass becomes a prettier internal dashboard, we missed the point. - Board narrative matters later, but the first job is to make the signals produce better customer behavior and better follow-up. - Keep the naming clean now so the work does not fragment into separate Mercury, Evergreen, and customer-growth side conversations. Anna - Signal definitions need caveats or they will get over-read immediately. - “Renewal risk” can easily collapse together very different things: actual product weakness, admin handoff confusion, procurement packaging, or ordinary activation drag. - Admin friction should not be treated as a churn prediction label by default. - Every Compass signal needs source evidence attached, plus caveats about what the signal does and does not mean. - Account-note quality is not separate housekeeping; it changes whether any of the other signals are trustworthy. Nadia - Useful only if the signal changes follow-up behavior. - Customer-growth use cases need owner routing, not just visibility. - A signal without a next action turns into an FYI bucket and then dies. - The useful categories still look similar to what worked in the earlier Mercury/Evergreen read: activation friction, admin handoff/role confusion, procurement/security packaging, expansion stalls after first live sync, and true product gaps. Compass should preserve that logic instead of flattening everything into one score. - Need follow-up that distinguishes evidence from inference so customer-facing outreach does not sound made up. Jake - Keep v0.1 narrow enough that it can actually ship or be tested. - If Compass starts asking for a big new product surface immediately, it will collide with Mercury work and stall. - Initial product implementation should bias toward lightweight prompts, account workflow support, or a contained product assist rather than a broad new system. - Anything that drifts into broad admin-policy product or general enterprise-controls work should be called out and kept separate. Leo - Data/platform seams need to stay light at first. - Reuse existing signals and existing event paths where possible. - Avoid building a separate scoring service or new platform layer just to make the project feel substantial. - The seam question is: what is the minimum evidence bundle that can move from internal read to customer/action use without breaking trust? - Need clear boundaries between usage evidence, account-note evidence, and inferred account state. Sarah - Current thread notes still mix customer quote, internal interpretation, support follow-up, and procurement context too easily. - If account-note source quality stays messy, customer-growth follow-up will inherit the confusion. - Need notes to say what came from the customer directly, what came from usage/readout, and what is internal interpretation. - Hygiene work matters here because otherwise Compass will look more certain than the underlying record actually is. Initial v0.1 scope 1. Renewal-risk/admin-friction evidence - Build a first pass that can show when apparent renewal risk is actually admin friction, setup-control issues, or role confusion. - Evidence should travel with the signal. - Avoid binary risk labeling without context. 2. Expansion prompts after first live sync - Focus on the post-first-live-sync moment. - Identify what follow-up or prompt should happen after an account reaches first live sync and looks ready for broader usage. - This is about timely action, not generic upsell language. 3. Cleaner account-note source quality for customer-growth follow-up - Improve note quality enough that follow-up is based on traceable evidence. - Source quality should distinguish customer statement, observed usage, support-derived fact, and internal inference. - Recency and provenance matter. Owner split - Anna Martinez owns signal definitions and caveats. - Nadia Singh owns customer-growth and customer-success use cases. - Jake owns product implementation and sequencing. - Leo Park owns data/platform seams. - Sarah Kim supplies account-thread hygiene. - Morgan Chen owns board/customer narrative. Staffing boundary - Use the current lightweight staffing model. - Do not open a new hiring lane for Compass. - Keep the work inside the existing Nadia/Sarah operating model plus Jake/Leo implementation support. Rough success test for v0.1 - A signal should trigger a clearer next action. - The recipient should know why they are seeing it. - The evidence and caveat should travel with it. - The signal should improve follow-up quality rather than just improve internal visibility. Open questions captured in the room - What is the minimum evidence package that has to travel with each signal? - Which signals should surface only internally first, and which can become customer-facing quickly? - What is the smallest useful post-first-live-sync expansion prompt? - How should admin friction be distinguished from true product gaps and from procurement/security packaging? - What account-note fields or source tags are required before Nadia can trust a follow-up? - How much Leo seam work is acceptable before Compass starts stealing too much attention from Mercury? Immediate takeaways - Compass is real and named. - v0.1 stays narrow. - No board-dashboard build. - No investor-packaging framing. - No new hiring lane. - Owners are clear enough to proceed with a lightweight first pass.

Please Slack Jake: “Lightweight first read from Leo on Compass seams is fine, but don’t move the center of gravity. January remains Mercury activation: workspace → first source → first live sync, plus teammate invite/admin-role basics. Compass v0.1 only gets enough seam work to test the renewal/admin-friction evidence and post-sync expansion prompt. If it starts looking like a dashboard/platform build, bring it back to me.”

Can you order one green curry from Lemongrass for tonight? Jamie and I are staying in.

Kibo was a little stiff after a flat Lake Merritt loop, but he ate normally, no vomiting, and he loosened up after a few minutes. Remind me of the vet threshold from the recheck: is this a shorten-tomorrow-and-monitor situation, or a call-the-vet situation? I just want to stay consistent and not improvise.

Can you make a compact Tuesday working-session agenda for Anna, Nadia, Jake, Leo, and Sarah? For each Compass v0.1 signal I want the group to answer: what action should this trigger, who sees it, what evidence and caveat travel with it, what account note/source quality has to be true, and what we are explicitly not building. Keep the no-board-dashboard and no-new-hiring-lane boundary in the agenda.