Run a developer relations program on Slab5

DevRel runs on lists. A list of upcoming events. A list of speaking slots. A list of community questions you owe answers to. A list of office-hours attendees who asked for follow-ups. A list of content pieces you owe by next Tuesday.

The problem is not the lists. The problem is they live in eight different tools, and the relationships between them disappear the moment you switch tabs.

One Slab5 workspace turns the lists into a system.

Content as a CMS collection

Every blog post, conference talk, sample app, and demo lives in a dev_content CMS collection with typed fields: title, format (post, talk, video, sample), audience, repository_url, published_at, related_modules.

Filtering by format gives you a content calendar. Filtering by related_modules tells you which product areas are under-covered.

Events as deals

Each conference talk or office-hours session is a deal on an Events pipeline. Stages: Proposed, Submitted, Accepted, Scheduled, Delivered, Followed Up. The Closed Lost stage tracks declined CFPs so you can see trend lines.

It sounds weird to model talks as deals. It stops being weird the first time you want to know your acceptance rate by conference or your average days from Submitted to Scheduled.

Community contacts and activity

Every developer who shows up at an event, asks a question on the forum, or files a community issue becomes a contact with source: "community". Activity Log records the interaction — a question answered, a sample they cloned, a talk they attended.

This is how you avoid the worst DevRel failure mode: the same engaged developer asks for the same thing twice, six months apart, and the second time they get the same generic answer because nobody remembered them.

Office hours as tasks

After each office-hours session, every promised follow-up is a task linked to the attendee's contact record. Tasks are due-dated, assignable, and visible in BI — so "how many open follow-ups do we have from last month's office hours" is one query, not an inbox search.

Community ticketing

Use the Support module for community questions that need a real answer. Queues by topic. Internal comments for the DevRel team. The SLA targets keep you honest about how long the community waits.

BI dashboards for the program

The DevRel-specific dashboard:

• Content pieces shipped this month, by format and module covered.
• Talks: acceptance rate, time from CFP to event.
• Open community follow-up tasks by owner.
• Open community tickets by topic.
• New community contacts this month vs last month.

Every number is one query against the workspace, not a spreadsheet you maintain by hand.

The agent your team needs

Give a DevRel agent the agent workspace role and these coarse scopes: crm:read, crm:write, tasks:write, support:read, activity:read, activity:write, cms:read. It can: deduplicate community contacts, draft follow-up tasks after office hours from the transcript, summarize the week's tickets for your standup.

It cannot send customer-facing messages (it shouldn't call add_support_ticket_message), it cannot publish content (the cms:write scope lets it draft and transition to review, but your editorial convention keeps publishing in a human's hands), and it cannot administer the workspace (the agent role takes care of that).

DevRel agent with the agent workspace role. Coarse scopes: crm:read, crm:write, tasks:write, support:read, activity:read, activity:write, cms:read. Convention: drafts only, never add_support_ticket_message. Audit log catches drift.

POST /v1/contacts from event signups. POST /v1/tasks for follow-ups. GET /v1/cms/entries?collection=dev_content for content calendar. BI queries for the program dashboard.