Appearance
Lazer FDE Onboarding for Avoca
Lazer-side companion to Avoca's Engineering Onboarding. Covers what to request, who to meet, and how the engagement works day-to-day. Update this doc as your first deliverable when you join.
Source
Originally drafted by Jordon McKoy (March 2026). Folded into the toolkit doc site by Sandy Corsillo, 2026-05-12, with merges from current toolkit references.
What this doc is
Related proposal
There's a separate Lazer-side proposal for evolving how this onboarding ramp works: Lazer FDE Ramp Model (proposal). This doc describes the current state; that one argues for a staged five-phase model. Read both if you're a new FDE; refer to this one as the operating reference.
Two things separate Lazer FDEs from Avoca FDEs:
- Customer context lives with Avoca FDEs. They own the client relationship and translate ambiguous asks into scoped work.
- Lazer FDEs execute scoped work inside Avoca's delivery system. Prompt changes, call-flow updates, integrations, backend workflows, debugging, PRs.
This doc is the bridge: how to ramp from "just got access" to "executing independently inside Avoca's process."
Companion docs (read in this order)
- This doc: what to request, who to meet, how the engagement works.
- Dev Env Access: verified smoke tests for credentials you've been issued.
- Engineering Onboarding: Avoca's internal technical reference, captured.
- Architecture Overview: system context with diagrams.
- Call Anatomy: end-to-end walkthrough of an Avoca call.
- Gotchas: surprises that bite.
Team & Key Contacts
Avoca, primary points of contact
| Name | Role | |
|---|---|---|
| Weber Gaowen | weber@avoca.ai | Main POC, overall direction, tracks work |
| Christine Munar | christine.munar@avoca.ai | Senior FDE, technical feedback, PR reviews, leads FDE weekly sync |
Avoca, engineering
| Name | Role |
|---|---|
| Joy Liu | FDE |
| Omkar Ingale | FDE |
| Peter Lehrman | FDE |
| Ella Gates | FDE |
| Neal Patel | FDE |
| Christian Scarlett | Product Engineer |
| Bharat Kilaru | Product Engineer |
| Juan | Product Engineer (most responsive for access requests) |
| Rong Ye | Product Engineer |
| Zakariyya Alquran | Software Engineer |
| Valeria Herrera | Technical Account Manager |
| Katie Ford | Account Executive |
Avoca, business
| Name | Role |
|---|---|
| Jack Corvin | VP of Sales |
Lazer internal
| Name | Role |
|---|---|
| Dev Maharaj | Delivery Manager |
| Aanikh Kler | AI Team Lead |
| Jordon McKoy | Engineer |
| Matt Harris | Engineer |
| Charles Blakely | Engineer |
| Sandy Corsillo | Engineer |
| Lauchlan Chisholm | Engineer |
Initial access checklist
Request all of the following from your manager. Juan at Avoca is usually the most responsive contact for access issues. Once provisioned, run the smoke test in Dev Env Access where one exists.
| Tool | Notes | Verified path |
|---|---|---|
GitHub (AvocaAI/avoca-next) | SSH key must have a passphrase, blank passphrase won't clone. Set local git email to your Avoca address. | Dev Env Access → GitHub |
| Avoca G Suite email | Weber creates this. Required for most system access. Enable 2FA for SOC2. | (none) |
| 1Password | Needed for ServiceTitan and Responder mail access. | (none) |
| Vercel (avoca team) | Needed for PR CI and to pull local env vars. | Dev Env Access → Vercel |
| Vapi dashboard | Voice agent platform admin. Never mention Vapi to clients. | (none) |
| Supabase | Primary database. | Dev Env Access → Supabase |
| Asana | Internal-only project tracker. Clients don't have access. | (none) |
| Notion | Avoca internal wiki. | (none) |
| Twilio | Phone number provisioning. Backup path if the Avoca voice-assistants page is down. | (none) |
| Claude, Cursor, ChatGPT | For prompt engineering work. | (none) |
| Datadog | Application logs. | Dev Env Access → Datadog |
| Avoca app admin | app.avoca.ai/admin, the engineer-facing dashboard. | (none) |
| Ngrok | For local webhook testing. Sign up with your Avoca email. | (none) |
How we work
Onboarding ramp, 3-ticket pairing
Lazer and Avoca agreed on a graduated onboarding approach:
- Ticket 1: Avoca engineer leads, you observe and contribute.
- Ticket 2: Worked on equally by both engineers.
- Ticket 3: You lead, Avoca provides support.
- Thereafter: Lazer engineers work independently.
Pacing
- Week 1: Onboarding and access setup.
- Weeks 2 to 3: Get familiar with systems, work on one customer account.
- Week 4+: Shift into testing and broader contributions once system-familiar.
How work gets assigned
Christine leads the FDE weekly sync. Tasks live in Asana on the FDE project board.
Work comes from two streams:
- Client requests (most often relayed through GTM/CS teammates).
- Internal engineering priorities.
Client-facing work takes priority. Get internal alignment before implementing changes that come directly from the client, since the client may request things that aren't in their best interest. You'll typically own prompt changes and post-call backend logic (post-call workflows that handle booking flows resulting in CRM updates) for an agent. It's your responsibility to track your work accordingly.
The client dynamic
Each account has a small pod: one or two engineers, a GTM specialist, and sometimes a CS rep. Clients range from hands-off to very involved. Some have technical teams you'll interface with directly; others are non-technical and just want things to work. You'll join client syncs and be expected to share updates.
Your aim is to ramp quickly and lead the technical aspect of these engagements. Client environments (staging vs. prod, CRM sandboxes) can be flaky or missing entirely. You may lose time to third-party access issues that aren't your fault. Flag them early rather than working around them silently.
Things that aren't obvious
- "Frontend" typically means the voice agent's prompt and configuration (hosted on Vapi), not the web UI. "Backend" means the post-call code that books appointments and writes to CRMs. "Dashboard" refers to the Avoca app (
app.avoca.ai, newerdashboard.avoca.ai). - Vapi is internal. Never mention it to clients. Most clients aren't aware of the third-party tools behind the scenes, and Avoca wants to keep them as internal knowledge.
- ServiceTitan is the CRM most customers use, but the accounts you'll likely touch are enterprise clients with custom CRM setups, which is why they need custom integration work.
- The codebase has legacy and current code paths side by side. Always confirm which path you're working on before making changes. New integrations default to the
/common/workflowwebhook endpoint. See Agent Architecture: Legacy vs Current.
PR and merge rules
- Contractors can review each other's code but should not approve each other's code. Get an Avoca engineer to review.
- Fill out the testing section as thoroughly as possible.
- Keep PRs as small as possible. Reviewers are busy with their own work; small, readable PRs get merged faster.
- A 5/5 greptile score is the gold standard; 4/5 is a good consistent target.
- You can hit merge when ready. If a change is scary or needs coordination, check with your Avoca lead first.
- Resolve all open PR comments, they block merges.
Practical gotchas (process-shaped)
These are surprises that hit you in the workflow, not the architecture. The full set lives in Gotchas → Process & Workflow. Highlights:
- SSH clone requires a passphrased key. Blank passphrase won't work.
is_internalflag in local dev shows all admin buttons. Toggle off before committing.- Supabase enum changes require type regeneration. CI will fail until types match.
- Clients can't see Asana, Vapi, or Datadog/Vercel. They only have Avoca dashboard access. Don't reference these to clients.
- Architecture docs can drift from code. Verify behavior in code before quoting a doc to a customer.
- No automated regression testing for prompt behavior yet. Hamming is the workaround until that's built.
Key resources
Toolkit doc site (this site)
The pages under Clients → Avoca are the canonical working reference for the engagement. Start with the companion docs section above.
Avoca engineering surfaces
| Resource | Link |
|---|---|
| avoca-next repo | github.com/AvocaAI/avoca-next |
| Call Debugger | app.avoca.ai/admin/call-debugger |
| CRM Tracker | app.avoca.ai/admin/crm-tracker |
| Vapi Test Case Setup (Loom) | loom.com/share/1bcebd8d99a845aca32431de3f4fbe55 |
Avoca Notion pages
| Resource | Notion link |
|---|---|
| Avoca Project Page | Notion |
| Common Booking Prompt Technical Docs | Notion |
| Bot Building Step-by-Step | Notion |
| Responder | Notion |
| New Vertical / CRM Integration Playbook | Notion |
| Template & Prompt Builder Deployment | Notion |
Updating this doc
Keep this doc current as your first deliverable. The fastest decay path for an onboarding handbook is "the person who just used it didn't update it."
When you onboard:
- Note anything that was wrong or out of date.
- Add anything that wasn't captured.
- Remove what you confirmed is no longer accurate.
Ping the most recent maintainer (Sandy as of May 2026) so the change propagates back.