Work · Paycor TAM team, expanding company-wide
In production
TAM Command Center & SOW Builder
One dashboard for the Technical Account Management team: build a Statement of Work in minutes, validate its legal language automatically, request time off, manage team work and see which engagements actually earn. It serves 29 users today and is becoming Paycor's company-wide SOW Builder as other teams' rates are added.
ProblemSOWs took over 20 minutes each, rates lived in a downloaded Excel workbook, time off lived in spreadsheets that drifted out of sync, and the team's tools were spread across separate sites.
BuiltA SOW builder with legal-language validation and an export for Legal review, central effective-dated rates, a time-off calendar, usage analytics, a test/live split and a Planner replica.
ResultAbout 85% less time per SOW for 29 users, one source of truth for rates and time off, and a platform now being extended to teams across the company.
22.5 → 3–4minutes to produce a SOW
100%of SOWs validated and exported for Legal
29users today, with a company-wide rollout underway
Copilot Studio (prototype)Dashboard designValidation rulesAnalyticsSalesforceMicrosoft PlannerDocuSign (planned)
Read the case study
The problem
Statements of Work are how the TAM team turns a customer's request into billable work. Each one took about 22.5 minutes to assemble by hand, and every manual edit carried a risk that someone changed contract language Legal had approved. Hourly rates came from an Excel workbook that had to be re-downloaded whenever a rate changed. Time off was tracked in spreadsheets that were often out of sync. Capacity was based on fixed estimates per engagement type, so it didn't show how busy each TAM really was, which made SLAs and headcount planning harder. Bookmarks, Planner boards and reports lived in different places.
Why a dashboard instead of an agent
I first designed the SOW Builder in Copilot Studio as an orchestrator: a parent agent handing each part of the SOW to its own child agent. Prototyping it showed that an "interview me" flow, where Copilot asks questions one at a time, was slower than a form that shows every field at once. I moved the build into a dashboard. Choosing the faster tool over the more impressive one is how the time dropped to 3–4 minutes.
What I built
- SOW Builder with validation. Every SOW is checked so approved legal language cannot be altered. Each build produces a validation report and an export that goes to Legal for review and acceptance.
- Central, effective-dated rates. Rates are stored and calculated inside the builder. A rate change can be dated in the future, so it takes effect on its own without anyone downloading a new workbook.
- Time-off calendar and requests. Replaces the spreadsheets with one calendar and a request flow that shows accurate availability.
- Usage statistics and business analytics. Compares engagement types, shows who credits or waives fees most and by how much, and lists repeat customers with their total spend with the team.
- Test and live environments. New features are tried in test so live statistics stay clean.
- Planner replica. A sub-team's Microsoft Planner board, managed inside the dashboard, removing a separate tool.
- Hours-based capacity (in progress). Capacity and utilization are moving from fixed estimates per engagement type to the hours each TAM is committed to each week, current and future. Managers get a true picture of who has room, TAMs can meet SLAs more consistently, and headcount requests rest on real workload data.
- Links & Resources. The team's most-used bookmarks in one place, so the dashboard is the starting point for the day.
What's next
- Company-wide SOW Builder. The builder serves 29 users on the TAM team today. As other teams provide their rates, I'm building them into a company-wide dashboard so every team that writes SOWs uses the same validated builder.
- DocuSign integration. Send the SOW for signature from the builder, then attach the fully executed copy to the matching IPW record in Salesforce automatically.
- Tax audit module. Pull and examine customer reports and flag likely problem areas for human review. Tax audits are one of the team's most expensive engagements.
- Quarterly audit subscription. Repeat the audit every quarter to catch setup errors early, reducing amended returns, late filings, penalties and interest for customers, and creating recurring revenue for the team.
- Customer self-service. Let clients start a TAM engagement inside Paycor, sign their part of the SOW and create the IPW in Salesforce automatically.
What it shows
Taking an operational process end to end: measuring the baseline, protecting what must not change (legal language, live data), centralizing sources of truth, and building toward revenue rather than only efficiency.
Personal · School operations
Used daily
UC Command Center
A dashboard that runs my degree: this week's plan synced live with Todoist, a semester calendar, grades with a GPA simulator, an academic advising tracker and statistics on study time versus results.
ProblemFive courses, a full-time job and deadlines spread across Canvas, syllabi, email and Todoist. No single view of what was due, how I was doing, or what to register for next.
BuiltAn installable web app wired to Todoist, with a shared database for grades, syllabi and advising notes, plus its own backlog and change log.
Result62 logged changes in the first 10 days. It replaced a weekly planner I rebuilt by hand and became the one place I check each morning.
62changes shipped and logged in 10 days
8views: planner, calendar, grades, advising, stats and more
Livetwo-way sync: click a task to complete it in Todoist
HTML · CSS · JavaScriptTodoist API via MCPShared databaseClaudePWA (installed as a Mac app)
Read the case study
Why I built it
I started with a printable weekly planner generated from Todoist. It worked, but keeping it current was a job in itself. The Command Center makes the planner live and adds the parts of school that had no home: grades, degree requirements and conversations with my advisor.
What it does
- This Week: tasks grouped by course and ordered by urgency, a "time left today" estimate, and automatic roll-forward of unfinished work that marks genuine overdue items differently from work started early.
- Calendar: assignments, UC academic dates, federal holidays, class meetings and my work PTO on one month view.
- Grades & GPA: a grade book per course and a GPA simulator that applies each syllabus's drop and replacement rules, with what-if scores that are never saved over real ones.
- Academic Advising: requirements remaining, courses I'm eligible to register for, alternative course plans and a log of advisor replies.
- Statistics: estimated effort by course and week compared with grades, so I can see where time is going.
- Admin: a backlog with statuses (Planned, In Progress, Not Planned, Done) and a dated change log. I run my own tool the way I'd run a product.
Decisions worth noting
- Todoist stays the source of truth. The dashboard reads and completes tasks but never rewrites an instructor's due date.
- Timezone safety: the date is always checked in Eastern time, after an early bug flagged work overdue hours before midnight.
- Every change is logged, so I can explain why the tool behaves the way it does.
AI workflow · Claude Skill + Todoist
v11
Self-Syncing Weekly Academic Planner
A reusable Claude Skill that reconciles a weekly planner with Todoist on one command. It marks completions, slots in new tasks, moves changed due dates, rolls work forward at midnight and archives finished days, and it flags every change instead of making it silently.
ProblemA printable planner drifted out of sync every time something changed in Todoist, and rebuilding it by hand happened several times a week.
BuiltA packaged Skill with written business rules, a live Todoist integration and an HTML template. Refined over 11 versions from failures caught in real use.
ResultA multi-step manual rebuild became one "/update" command I trust not to drop or misstate a deadline.
Claude SkillsTodoist MCPPrompt designHTML template
Read the case study
Design rules that came from real failures
- The planner is a view, not a copy. It can flag something overdue or move it on the page, but never changes a real due date in Todoist.
- Never silently delete. Completed work is crossed off and tagged, so progress stays visible.
- Check local time first. The server's "today" can roll over hours before Eastern midnight, which once caused work to be flagged overdue a day early.
- Encode judgment. Graded work outranks optional lecture videos unless a video is a prerequisite for something due soon. Lighter workloads land on Bengals game days when deadlines allow.
What I'd change for a team
Turn the natural-language rules into explicit, testable logic; add validation and logging so a person isn't the only safeguard; and separate the personal preferences from the reusable sync engine so it can be configured per user. Protecting a source of truth, reconciling state safely and encoding real business judgment is the same pattern behind client-facing automation, with more users and higher stakes.
Coursework · CS 1010 Intro to AI
Machine learning
Detecting Insurance Fraud: Decision Tree vs. SVM
Binary classification on 1,000 insurance claims (67 features, 24.7% fraud). I trained and compared two models on a stratified 75/25 split and recommended one based on the cost of a missed fraud, not accuracy alone.
QuestionWhich model better flags fraudulent claims when a model that always says "not fraud" is already about 75% accurate?
MethodOrange Data Mining workflow: categorical target, stratified split, Decision Tree and SVM, then confusion matrices, ROC curves, precision, recall, F1 and AUC.
FindingSVM, with an AUC of 0.812 vs. 0.685, ranks risky claims better and caught slightly more fraud. The tree is easier to explain to investigators.
0.812SVM AUC (tree: 0.685)
67.7%SVM recall: 42 of 62 frauds caught
0.599Decision Tree F1, the better balance at default threshold
Orange Data MiningClassificationROC / AUCModel evaluation
Limitations I called out
- Class imbalance pushes both models toward predicting "not fraud."
- Both models used default settings; tuning tree depth or the SVM kernel and cost could help.
- One 75/25 split; cross-validation would give a more reliable estimate.
- Next models to try: Random Forest and Logistic Regression.
