Bitkern

Bitkern buys mining hardware for its clients, ships it to hosting sites around the world, and keeps it running through the site operators, handling logistics, repairs, and the billing that follows. The company already worked in Asana, built out for the core business and loosely for the rest. Zendesk handled tickets and HubSpot held deals, with no connection to Asana. When the program lead and the operations lead came to us through Upwork in July 2025, they were direct about the priority. Asana's notifications, in their words, added no value. A repair card carried five or six pre-assigned people and dependent subtasks, so the moment a card was created everyone was notified about work they could not start yet. People ended up with a massive inbox and could address about a tenth of it. Billing triggers were spread across Google Sheets, Asana cards, and email, the same data was re-keyed across boards, and marketing and IT had no structure at all.

This was an Asana implementation. We spent years implementing work management platforms, Asana among them, and this is that work.

Discovery ran as four calls over the summer of 2025 with the program lead, operations, billing, and support staff, working from a process map the client had already drafted, listing every department, task, and subtask with its intended owner and whether an Asana task existed for it. From that we scoped a governed, exception-first operating model in Asana, beginning at hosting launch (deal tracking stayed in the CRM), with enforceable gates, clear SLAs, low notification noise, and manual intake rather than a CRM integration.

The hosting launch became the operational entry point. An intake form creates a task from a template with required fields, a Go/No-Go gate that blocks downstream work until it is set to Go, SLA controls on rack-ready and power-on checkpoints that move a task to an SLA Breach section and notify operations, and duplicate-check controls (a required deal ID and CRM link, a saved duplicate-check view, and a rule that only the intake owner can activate a launch).

Repairs, customer support, and billing were linked into one enforced chain. A repair marked ready for support creates a linked support ticket, and a support verification creates a linked billing task carrying the customer, amount, invoice type, due date, and a computed flag for whether executive approval is needed. A billing board tracks uninvoiced, sent, partial, paid, and overdue, with saved views for billing, an approvals view for the CEO, overdue buckets, and reusable dunning checklists. Incoming invoices got an approval chain from department owner to accounting to CEO above a threshold, a month-close view, and a comment-based approval trail.

One department board holds intake, active, approvals needed, waiting on client, SLA breach, ready to invoice, and overdue, with executive saved views for today's risks, approvals needed, and overdue invoices that show only exceptions. Marketing got a content calendar with an approval step and an at-risk flag. IT got a request board with SLA lanes and an escalation rule. Later change orders added an overdue invoice shutdown and reactivation workflow and an incoming invoices flow. Delivery included a field dictionary, SOP cheat sheets per board, and UAT signed off jointly by operations and billing.

Notifications went from everyone-at-creation to the next person when their step is ready, which was the thing the client said they needed fixed first. A hosting launch cannot exist twice for the same deal, and it cannot proceed without a Go decision. A repair does not reach billing without a support verification, and a billing task arrives already carrying what billing needs, instead of being reassembled from a spreadsheet, a card, and an email. Executives open one saved view and see risks, approvals, and overdue invoices rather than a feed of completed tasks. Marketing and IT requests have a place to land and an SLA. The build followed in the fall of 2025, and the client extended it by change order.

Given the same problem now, we would build Bitkern an operations system of its own that holds hosting launches, the miner fleet by site, repairs, support, billing, and approvals in one database, with Zendesk and the CRM as native connections, notifications designed per role from the start, and no per-seat licensing for site technicians who only need to update a status. The Asana build enforces the process it was designed to enforce. A client-owned system removes the workarounds a general-purpose tool requires (saved views as gates, comment trails as audit logs) and makes fleet, repair, and billing data one queryable record.