Engineering AI

OtiumWork's Engineering section is the tech-support flavor of the Peter AI assistant. Sales reps use Peter to nurture prospects through the Challenger sale; engineers use the same plumbing but with a different prompt scaffold — one that's tuned to resolve technical questions, reference internal docs, and stay clear of sales moves.

Eligibility: anyone with employee.persona_mode = 'engineering' (or admins). Set by an admin from the employee record. Developer accounts (the is_developer "dev user type") also get the TPOC View — it's a technical team dashboard — but not the sales-tuned surfaces (Drafts, Customer meetings, Engineering AI config).

Four surfaces

TPOC View (/engineering/tpoc-view)

The shared team dashboard for tech-point-of-contact assignments. Each engineer's accounts are grouped together with at-a-glance health columns:

• Last touch (resource-center activity of the first listed contact) plus a separate Real last touch column you fill in by hand for the actual customer touch — meeting, call, on-site. Both are colour-coded green (≤30d) / amber (31-89d) / red (≥90d).
• Next meeting is auto-joined from your Outlook calendar — any future external-attendee meeting whose attendee matches the row's POC email or domain.
• Tech support expires with days-to-expiration pill.
• Filter pills at the top: Tech support (Active / Expiring ≤90d / Expired) and SF match (No SF match / Loose match) for quick triage.

Per-row buttons:

• 🔧 — Set or clear the SF Account override. Use this when the auto-matcher gets the wrong Account (or none).
• ✎ — Edit any field. Salesperson / Tech support expiration / Comments push through to Salesforce. Real last touch / priority / POC name stay local.
• ✨ — AI-generated 5-bullet account briefing. Pulls row data + extra contacts + last 5 SF Tasks, asks Claude Haiku for a tight summary. Cached on the row; click Regenerate to refresh.
• 👥 — Manage all contacts at the account beyond the primary POC. SF Contact ID auto-resolves from email where possible. The number shows how many extra contacts are tracked.
• ✉ — Compose and send an email from your connected Outlook mailbox (saved to your Sent Items).
• 📝 — View the last 10 SF Tasks on the account and add a new "TPOC note" Task inline. Single source of truth: notes live in Salesforce, not in OtiumWork.
• 🗑 — Remove the TPOC row (doesn't touch Salesforce).

Customer meetings (/engineering/meetings)

Customer-attended meetings synced from your Outlook calendar — past 30 days and next 14 days. The list is split into Past (most recent first) and Upcoming (soonest first). Any meeting with at least one external attendee (non-@<company>.com address) shows up.

• Add notes per meeting in the inline text box. Saved locally so you keep a personal resolution log.
• Save & sync to SF mirrors the notes to Salesforce as a Task on the matched record:
• First we try exact email match → SF Lead/Contact (Task on Contact + Account).
• If no Contact exists, we fall back to domain match → SF Account (Task attaches to the Account directly). Common case: SoftInWay has the Account in SF but the specific engineer the customer sent isn't yet a Contact.
• Re-saving updates the same Task (idempotent via work_event.sf_activity_id).
• Hide filters personal reminders that aren't real customer meetings (e.g. "pick up the kids" with a single external attendee). Click "Show hidden" to recover.

Salesforce sync uses the company-level SF connection — engineers don't need to connect their own SF. All engineering meeting Tasks attribute to the shared tenant SF token.

Drafts (/engineering/drafts)

Peter watches your inbox and drafts tech-support replies in your voice (see Voice tuning below). Drafts land in your Outlook Drafts folder — you review, edit, send.

Connect once at the top of the page (separate OAuth from the calendar Outlook — needs Mail.ReadWrite + Mail.Send scopes so Peter can write drafts on your behalf).

• Autonomy controls under the disclosure:
• 0 — Drafts only. Peter never sends. Everything goes to your Drafts.
• 1 — Drafts + ask. Same as 0 today; reserved for an approval queue later.
• 2 — Auto-send routine replies. Peter sends low-stakes replies automatically; novel or higher-stakes stays in Drafts.
• Auto-draft toggle: turn off if you want the connection live (for sent-items scraping + command answering) but no inbound-reply drafts.

The drafts you see in Recent activity are status snapshots — drafted, auto-sent, skipped, not a lead. "View in Outlook" opens the actual draft for editing.

Engineering AI config (/engineering/config)

Two fields, both tune what Peter writes for you:

• Engineering knowledge base (company-wide) — product docs, FAQs, version gotchas, escalation paths. Visible to every engineering rep on the tenant. Lives in sales_ai_company_config.engineering_kb.
• Personal style notes — your voice, tone, escalation preferences. Same column as the sales-side per-rep style (employee.personal_style_notes).

Voice tuning

A new engineer can generate a draft of their personal_style_notes from their last 6 months of customer-facing sent mail. Pattern (one-shot, admin-run):

1. Connect Sales-AI Outlook.
2. Admin runs scripts/seed_<rep>_demo_drafts.py (or the voice-analysis script). Pulls ~30-50 external sent emails, asks Claude to extract tone / structural patterns / recurring phrases / tech-support reflexes, returns a ready-to-paste markdown block.
3. Paste into /engineering/config → Personal style notes → Save.
4. Optional: seed a handful of [Demo]-prefixed drafts in the engineer's Outlook Drafts so they can preview what Peter-in-their-voice produces before a real inbound arrives.

Differences from sales Peter

	Sales (default)	Engineering
System prompt	Challenger framework, qualifying questions, next-step propose	Resolve technical question, reference KB, escalate when needed
Calendar link	Push when prospect signals interest	Never push (no "grab time on my calendar")
Sales-shaped inbounds	Engage / qualify	Punt to Sales team gracefully
KB source	sales_ai_company_config.knowledge_base	sales_ai_company_config.engineering_kb
Pricing / commercial	Engage (Sales rep follow-up)	Never quote; route to peter@ or Sales

Operating notes

• The same desktop client / calendar sync / Outlook OAuth infrastructure powers both modes — no separate setup beyond connecting one extra Outlook scope for the drafts pipeline.
• Engineering meeting Tasks created in Salesforce attribute to the company SF user, not the individual engineer. Engineers are named in the Task description for traceability.
• The Peter poll runs every ~5 min; drafts for new inbound external emails appear within minutes.

SoftInWay Services API + VPN

Configure tenant access at Network → Network & VPN (sidebar). This page is developer-gated: anyone with the is_developer flag can manage it without holding the full admin role (admins can reach it too). It deliberately lives off the finance-gated Admin → Settings page so an engineer who configures IP/tunnels doesn't need broad admin rights. To grant it, an admin sets a person's developer flag in Admin → Employees → Edit (the dev flag also removes them from people-analytics and finance — it's meant for technical/tooling access).

1. API URL + key — what OtiumWork uses when making calls (e.g. for tech-support date sync).
2. VPN tunnels — add one tunnel per network you need to reach (prod, dev, staging, …). Each row needs:
   • Slug — short id used in the systemd unit name (e.g. prod → wg-quick@wg-svc-prod)
   • Label — human-friendly name shown in the admin table
   • Type — WireGuard, OpenVPN, or L2TP/IPSec (PSK)
   • Config — full .conf / .ovpn body (WireGuard/OpenVPN)
   • Enabled — uncheck to keep the row but stop bringing it up

L2TP/IPSec tunnels (e.g. the Burlington office VPN)

Everything about an L2TP/IPSec tunnel is set here, not on the server:

• Gateway, pre-shared key, username, password — from IT. When you Edit an existing tunnel, leave the key or password blank to keep the stored one (so rotating the password doesn't mean re-typing the key). Secrets are never shown back.
• Routes through the tunnel — one per line, e.g. 172.25.0.0/16 via 172.25.6.1 for the Burlington LAN. Added when the link comes up, removed when it drops.
• PPP authentication — CHAP (default) or MS-CHAPv2. Burlington uses CHAP.
• Force UDP encapsulation (NAT-T) — on by default. Wraps the encrypted traffic in UDP 4500. Burlington's gateway drops raw ESP, so with this off the tunnel negotiates but never carries traffic.
• Reconnect automatically — on by default. The server checks every minute and redials a dropped link (encryption first; it never connects without encryption). After 3 failed tries it slows to every 10 minutes so the router doesn't block us, and sends a Telegram alert. If it ever finds the link connected without encryption, it hangs up and alerts.

Saving applies it within about a minute — no deploy or SSH needed. The Status column shows what the server reports: Up, encrypted (with the tunnel IP), Down (with failed redials), Unencrypted, hung up, or Down, auto-reconnect off. Status stale means the server's checker has stopped reporting; last apply failed means the saved settings couldn't be applied (details in /var/log/otium-vpn-apply.log on the server).

WireGuard / OpenVPN tunnels

These are applied on the next deploy: bash deploy/deploy-prod.sh walks the table, writes configs to /etc/wireguard/ and /etc/openvpn/client/, and brings the matching systemd units up. Tunnels deleted in the UI are torn down then too.