A local-service path from plan comparison to the existing booking system.
Saltglass migrated and redesigned the site around four service plans, service-area journeys, and a clear handoff to Jobber without replacing the client's scheduling system.
Audience
Residential and commercial customers
Customer action
Compare a plan and request service
Systems involved
Local pages, plan content, Jobber
Saltglass services
Migration, redesign, booking journey, launch
The business problem
A service website has to answer local questions before asking someone to book.
Kraken Bin Cleaners serves residential and commercial customers across defined service areas. Before a customer reaches the request form, the site has to explain what is cleaned, where service is available, which plan fits, and what happens next.
The existing Jobber workflow already handled customer requests and scheduling. Replacing it would have created more work for the team, so the public site was designed to prepare the customer and pass the request into the system the business already uses.
Scope boundary: Saltglass handled the website migration, public experience, plan structure, service-area paths, and Jobber handoff. The Kraken rebrand itself was not claimed as Saltglass work.
What had to stay intact
Four plans, local routes, and the existing booking record.
The project had to carry the business from its previous Bin Bros web presence into the Kraken site without losing the service information customers relied on. City and service-area routes needed to remain useful, and Jobber needed to remain the scheduling system of record.
What Saltglass handled
A clearer decision path before the booking form.
Migrated and redesigned the public website
Organized four service plans for easier comparison
Separated residential and commercial entry points
Connected city and service-area pages to the right next action
Preserved Jobber for request intake and scheduling
Kept payment and operational scheduling out of the public site
Customer journey
The public site prepares the customer, then Jobber records the request.
Local or service page→Plan comparison→Jobber request form→Client scheduling workflow
Why this matters to the business
The website and the booking tool each do the job they are best suited to do.
Customers get enough context to choose a service before entering a form. Staff keep working inside Jobber instead of learning a second scheduling system or copying requests by hand.
Clearer plan choices
Customers can compare service frequency and fit before they request an appointment.
Local context
Service-area and city pages answer whether the business serves the customer before the booking handoff.
One request record
Jobber remains the place where the team receives and manages the request.
What the system supports
Customers can choose a relevant path before entering the booking system.
Confirm the service area
Compare four service plans
Choose residential or commercial service
Continue to the existing Jobber request form
Keep scheduling inside the client workflow
The public site explains the service before handing the customer to Jobber.
Relevant services
Website modernization and service-booking journeys.
Contact